1.0beta10 first attempt, on non-Jetty, getting ContinuationFilter errors
46 views
Skip to first unread message
neek
Jul 20, 2009, 1:01:37 AM7/20/09
to cometd-users
Hi there,
I'm trying beta10, having had little success with earlier betas, on
Glassfish v3 preview i.e. not Jetty. beta10 built via Maven first
try, which was very nice, but I get exceptions in my glassfish log
when running my simple test app.
I've copied the maven-built .jar files into the glassfish domain lib
dir, satisfying all the ClassNotFound exceptions which prevented
startup. This is a completely fresh eclipse 3.5 install with beta10
jars only. My test app is the only app deployed, so there is no
confusion over multiple contexts being deployed and me hitting the
cometd servlet in another context.
My app is a very simple dojo based web client (a .html page with
necessary dojo wiring) and a web.xml that declares the filter, and the
continuation servlet. The web page connects to the cometd servlet,
subscribes to a channel, and a pushbutton publishes to the channel.
The client connects ok, and can publish and receive those published
messages via the comet servlet. Surprisingly, despite this basic
success, I still get an '500' server error logged by Firebug, and the
glassfish log shows this exception, every few seconds (i.e. standard
backoff-controlled error mechanism driven by the dojo cometd client):
SEVERE: StandardWrapperValve[cometd]: PWC1406: Servlet.service() for
servlet cometd threw exception
java.lang.IllegalStateException: !(Jetty || Servlet 3.0 ||
ContinuationFilter)
at org.eclipse.jetty.continuation.ContinuationSupport.getContinuation
(ContinuationSupport.java:129)
at org.eclipse.jetty.continuation.ContinuationSupport.getContinuation
(ContinuationSupport.java:141)
at org.cometd.server.continuation.ContinuationCometdServlet.service
(ContinuationCometdServlet.java:160)
at org.cometd.server.AbstractCometdServlet.service
(AbstractCometdServlet.java:238)
... cut ...
My web.xml does define the ContinuationFilter, all is as it should be
as far as I can tell, copied directly from the cometd-demo/target/
cometd-demo-1.0.beta10/WEB-INF/web.xml file.
If I have the ContinuationFilter correctly defined, should it be
possible to still get that exception thrown? Glassfish v3 claims to
be a 'servlet 3.0' container, so according to that exception error
message I should not need the ContinuationFilter, but I get the same
errors with or without it.
Thank you for your patience :)
I'm trying beta10, having had little success with earlier betas, on
Glassfish v3 preview i.e. not Jetty. beta10 built via Maven first
try, which was very nice, but I get exceptions in my glassfish log
when running my simple test app.
I've copied the maven-built .jar files into the glassfish domain lib
dir, satisfying all the ClassNotFound exceptions which prevented
startup. This is a completely fresh eclipse 3.5 install with beta10
jars only. My test app is the only app deployed, so there is no
confusion over multiple contexts being deployed and me hitting the
cometd servlet in another context.
My app is a very simple dojo based web client (a .html page with
necessary dojo wiring) and a web.xml that declares the filter, and the
continuation servlet. The web page connects to the cometd servlet,
subscribes to a channel, and a pushbutton publishes to the channel.
The client connects ok, and can publish and receive those published
messages via the comet servlet. Surprisingly, despite this basic
success, I still get an '500' server error logged by Firebug, and the
glassfish log shows this exception, every few seconds (i.e. standard
backoff-controlled error mechanism driven by the dojo cometd client):
SEVERE: StandardWrapperValve[cometd]: PWC1406: Servlet.service() for
servlet cometd threw exception
java.lang.IllegalStateException: !(Jetty || Servlet 3.0 ||
ContinuationFilter)
at org.eclipse.jetty.continuation.ContinuationSupport.getContinuation
(ContinuationSupport.java:129)
at org.eclipse.jetty.continuation.ContinuationSupport.getContinuation
(ContinuationSupport.java:141)
at org.cometd.server.continuation.ContinuationCometdServlet.service
(ContinuationCometdServlet.java:160)
at org.cometd.server.AbstractCometdServlet.service
(AbstractCometdServlet.java:238)
... cut ...
My web.xml does define the ContinuationFilter, all is as it should be
as far as I can tell, copied directly from the cometd-demo/target/
cometd-demo-1.0.beta10/WEB-INF/web.xml file.
If I have the ContinuationFilter correctly defined, should it be
possible to still get that exception thrown? Glassfish v3 claims to
be a 'servlet 3.0' container, so according to that exception error
message I should not need the ContinuationFilter, but I get the same
errors with or without it.
Thank you for your patience :)
Greg Wilkins
Aug 11, 2009, 8:15:36 PM8/11/09
to cometd...@googlegroups.com
neek wrote:
> Hi there,
>
> I'm trying beta10, having had little success with earlier betas, on
> Glassfish v3 preview i.e. not Jetty. beta10 built via Maven first
> try, which was very nice, but I get exceptions in my glassfish log
> when running my simple test app.
> Hi there,
>
> I'm trying beta10, having had little success with earlier betas, on
> Glassfish v3 preview i.e. not Jetty. beta10 built via Maven first
> try, which was very nice, but I get exceptions in my glassfish log
> when running my simple test app.
neek,
the code that is trying to detect a servlet 3 container is:
boolean servlet3Support=false;
Constructor<? extends Continuation>s3cc=null;
try
{
boolean servlet3=ServletRequest.class.getMethod("startAsync")!=null;
if (servlet3)
{
Class<? extends Continuation> s3c =
ContinuationSupport.class.getClassLoader().loadClass("org.eclipse.jetty.continuation.Servlet3Continuation").asSubclass(Continuation.class);
s3cc=s3c.getConstructor(ServletRequest.class,
ServletResponse.class);
servlet3Support=true;
}
}
catch (Exception e)
{}
finally
{
__servlet3=servlet3Support;
__newServlet3Continuation=s3cc;
}
Could you perhaps put that into a little test class and run it within
your glassfish environment and see at what step it is failing?
[ I'll make sure we don't have an empty catch block in the next release ]
Is it that there is no startAsync on the request class you are running
against, or is it that the reflection code cannot fine the Servlet3Continuation
continuation implementation?
thanks
neek
Aug 13, 2009, 11:20:53 PM8/13/09
to cometd-users
Sorry, I only just noticed your response.
On Aug 12, 7:15 am, Greg Wilkins <gr...@mortbay.com> wrote:
> Is it that there is no startAsync on the request class you are running
> against, or is it that the reflection code cannot fine the Servlet3Continuation
> continuation implementation?
It looks like the Servlet3Continuation constructor doesn't have the
expected signature. It only takes a ServletRequest parameter.
I sprinkled some log statements among your code, above, and put in a
logger in the catch:
INFO: init here
INFO: Testing class javax.servlet.ServletRequest
INFO: getMethod("startAsync")!=null returned true
INFO: Got s3c=class
org.eclipse.jetty.continuation.Servlet3Continuation
SEVERE: Exception:
org.eclipse.jetty.continuation.Servlet3Continuation.<init>
(javax.servlet.ServletRequest, javax.servlet.ServletResponse)
java.lang.NoSuchMethodException:
org.eclipse.jetty.continuation.Servlet3Continuation.<init>
(javax.servlet.ServletRequest, javax.servlet.ServletResponse)
at java.lang.Class.getConstructor0(Class.java:2706)
at java.lang.Class.getConstructor(Class.java:1657)
at test.GregTest.init(GregTest.java:55)
at org.apache.catalina.core.StandardWrapper.initServlet
(StandardWrapper.java:1409)
at org.apache.catalina.core.StandardWrapper.load(StandardWrapper.java:
1212)
at org.apache.catalina.core.StandardContext.loadOnStartup
(StandardContext.java:4999)
[cut]
Looking in jetty-continuation-7.0.0.M4.jar, Eclipse's decompiler shows
me the signature of the constructor for
org.eclipse.jetty.continuation.Servlet3Continuation:
public Servlet3Continuation(javax.servlet.ServletRequest request);
Changing the 'getConstructor()' line to this, of course, results in no
exception and servlet3Support=true:
s3cc=s3c.getConstructor(ServletRequest.class);
So is this a problem with the jetty-continuation-7.0.0.M4.jar source
or the cometd servlet source?
I'd love to try fixing at least this one liner, but it's in the Jetty
source. Should I go and try to modify the org/eclipse/jetty/
continuation/ContinuationSupport.java to change the failing
getConstructor() call? I'm guessing it should be easy to pull the
entire Jetty source using Maven, but I don't know how to go about
doing that (yet).
- http://docs.codehaus.org/display/JETTY/Jetty7+-+Building+from+Source
talks about getting trunk, how do I get the 7.0.0.M4 source so I may
make modifications to the libraries that cometd beta10 ships with?
- "svn co http://svn.codehaus.org/jetty/jetty/trunk jetty" gets me a
buildable tree but I don't seem to end up with
ContinuationSupport.java, just the .class and jetty-
continuation-7.0.0.M4.jar.
Cheers
Nick
On Aug 12, 7:15 am, Greg Wilkins <gr...@mortbay.com> wrote:
> Is it that there is no startAsync on the request class you are running
> against, or is it that the reflection code cannot fine the Servlet3Continuation
> continuation implementation?
expected signature. It only takes a ServletRequest parameter.
I sprinkled some log statements among your code, above, and put in a
logger in the catch:
INFO: init here
INFO: Testing class javax.servlet.ServletRequest
INFO: getMethod("startAsync")!=null returned true
INFO: Got s3c=class
org.eclipse.jetty.continuation.Servlet3Continuation
SEVERE: Exception:
org.eclipse.jetty.continuation.Servlet3Continuation.<init>
(javax.servlet.ServletRequest, javax.servlet.ServletResponse)
java.lang.NoSuchMethodException:
org.eclipse.jetty.continuation.Servlet3Continuation.<init>
(javax.servlet.ServletRequest, javax.servlet.ServletResponse)
at java.lang.Class.getConstructor0(Class.java:2706)
at java.lang.Class.getConstructor(Class.java:1657)
at test.GregTest.init(GregTest.java:55)
at org.apache.catalina.core.StandardWrapper.initServlet
(StandardWrapper.java:1409)
at org.apache.catalina.core.StandardWrapper.load(StandardWrapper.java:
1212)
at org.apache.catalina.core.StandardContext.loadOnStartup
(StandardContext.java:4999)
[cut]
Looking in jetty-continuation-7.0.0.M4.jar, Eclipse's decompiler shows
me the signature of the constructor for
org.eclipse.jetty.continuation.Servlet3Continuation:
public Servlet3Continuation(javax.servlet.ServletRequest request);
Changing the 'getConstructor()' line to this, of course, results in no
exception and servlet3Support=true:
s3cc=s3c.getConstructor(ServletRequest.class);
So is this a problem with the jetty-continuation-7.0.0.M4.jar source
or the cometd servlet source?
I'd love to try fixing at least this one liner, but it's in the Jetty
source. Should I go and try to modify the org/eclipse/jetty/
continuation/ContinuationSupport.java to change the failing
getConstructor() call? I'm guessing it should be easy to pull the
entire Jetty source using Maven, but I don't know how to go about
doing that (yet).
- http://docs.codehaus.org/display/JETTY/Jetty7+-+Building+from+Source
talks about getting trunk, how do I get the 7.0.0.M4 source so I may
make modifications to the libraries that cometd beta10 ships with?
- "svn co http://svn.codehaus.org/jetty/jetty/trunk jetty" gets me a
buildable tree but I don't seem to end up with
ContinuationSupport.java, just the .class and jetty-
continuation-7.0.0.M4.jar.
Cheers
Nick
neek
Aug 17, 2009, 4:00:25 AM8/17/09
to cometd-users
On Aug 14, 10:20 am, neek <neekfenw...@gmail.com> wrote:
> Should I go and try to modify the org/eclipse/jetty/
> continuation/ContinuationSupport.java to change the failing
> getConstructor() call?
I've managed to get and build Jetty-7 trunk and fix this one-liner to
> Should I go and try to modify the org/eclipse/jetty/
> continuation/ContinuationSupport.java to change the failing
> getConstructor() call?
produce a fixed jetty-continuations jar. Running in glassfish now
gets around the previous error. I now get an exception:
SEVERE: StandardWrapperValve[cometd]: PWC1406: Servlet.service() for
servlet cometd threw exception
at org.apache.catalina.connector.Request.startAsync(Request.java:
4056)
at org.apache.catalina.connector.Request.startAsync(Request.java:
3994)
at org.apache.catalina.connector.RequestFacade.startAsync
(RequestFacade.java:1032)
at org.eclipse.jetty.continuation.Servlet3Continuation.suspend
(Servlet3Continuation.java:138)
at org.cometd.server.continuation.ContinuationCometdServlet.service
(ContinuationCometdServlet.java:171)
at org.cometd.server.AbstractCometdServlet.service
(AbstractCometdServlet.java:250)
at org.apache.catalina.core.StandardWrapper.service
(StandardWrapper.java:1506)
[cut]
This happens on the third message sent to the cometd servlet. My
client only makes a connection, it does not subscribe or do anything
else. The first are a handshake and a connect, then the third throws
this exception (exceptions then continue as per reconnect advice).
Full server log follows:
Aug 17, 2009 2:48:21 PM
com.sun.enterprise.security.web.GlassFishSingleSignOn invoke
FINE: Process request for '/v3test2cometd-java/cometd'
Aug 17, 2009 2:48:21 PM
com.sun.enterprise.security.web.GlassFishSingleSignOn invoke
FINE: Checking for SSO cookie
Aug 17, 2009 2:48:21 PM
com.sun.enterprise.security.web.GlassFishSingleSignOn invoke
FINE: SSO cookie is not present
Aug 17, 2009 2:48:21 PM
com.sun.enterprise.web.PESessionLockingStandardPipeline lockSession
FINEST: IN LOCK_SESSION: sess =null
Aug 17, 2009 2:48:21 PM com.sun.web.server.J2EEInstanceListener
instanceEvent
FINEST: *** InstanceEvent: BEFORE_SERVICE_EVENT
Aug 17, 2009 2:48:21 PM org.apache.catalina.core.ApplicationContext
log
INFO: PWC1412: WebModule[/v3test2cometd-java] ServletContext.log
():newTransport: client=null,message={"id":
1,"supportedConnectionTypes":["long-
polling"],"minimumVersion":"0.9","channel":"/meta/handshake","ext":
{"ack":true},"version":"1.0"}
Aug 17, 2009 2:48:21 PM org.apache.catalina.core.ApplicationContext
log
INFO: PWC1412: WebModule[/v3test2cometd-java] ServletContext.log
():newTransport: result=org.cometd.server.JSONTransport@1c8b69b
Aug 17, 2009 2:48:21 PM org.apache.catalina.core.ApplicationContext
log
INFO: PWC1412: WebModule[/v3test2cometd-java] ServletContext.log
():newClient: 10tqe6rtux0i2zokw
Aug 17, 2009 2:48:21 PM org.apache.catalina.core.ApplicationContext
log
INFO: PWC1412: WebModule[/v3test2cometd-java] ServletContext.log
():handshake.handle: reply=
{"minimumVersion":"0.9","supportedConnectionTypes":["long-
polling","callback-polling"],"successful":true,"channel":"/meta/
handshake","advice":{"reconnect":"retry","interval":0,"timeout":
30000},"clientId":"10tqe6rtux0i2zokw","version":"1.0"}
Aug 17, 2009 2:48:21 PM com.sun.web.server.J2EEInstanceListener
instanceEvent
FINEST: *** InstanceEvent: AFTER_SERVICE_EVENT
Aug 17, 2009 2:48:21 PM
com.sun.enterprise.web.PESessionLockingStandardPipeline unlockSession
FINEST: IN UNLOCK_SESSION: sess = null
Aug 17, 2009 2:48:21 PM
com.sun.enterprise.security.web.GlassFishSingleSignOn invoke
FINE: Process request for '/v3test2cometd-java/cometd'
Aug 17, 2009 2:48:21 PM
com.sun.enterprise.security.web.GlassFishSingleSignOn invoke
FINE: Checking for SSO cookie
Aug 17, 2009 2:48:21 PM
com.sun.enterprise.security.web.GlassFishSingleSignOn invoke
FINE: SSO cookie is not present
Aug 17, 2009 2:48:21 PM
com.sun.enterprise.web.PESessionLockingStandardPipeline lockSession
FINEST: IN LOCK_SESSION: sess =null
Aug 17, 2009 2:48:21 PM com.sun.web.server.J2EEInstanceListener
instanceEvent
FINEST: *** InstanceEvent: BEFORE_SERVICE_EVENT
Aug 17, 2009 2:48:21 PM org.apache.catalina.core.ApplicationContext
log
INFO: PWC1412: WebModule[/v3test2cometd-java] ServletContext.log
():newTransport: client=10tqe6rtux0i2zokw,message={"id":
2,"connectionType":"long-polling","channel":"/meta/
connect","clientId":"10tqe6rtux0i2zokw"}
Aug 17, 2009 2:48:21 PM org.apache.catalina.core.ApplicationContext
log
INFO: PWC1412: WebModule[/v3test2cometd-java] ServletContext.log
():newTransport: result=org.cometd.server.JSONTransport@f7ba93
Aug 17, 2009 2:48:21 PM com.sun.web.server.J2EEInstanceListener
instanceEvent
FINEST: *** InstanceEvent: AFTER_SERVICE_EVENT
Aug 17, 2009 2:48:21 PM
com.sun.enterprise.web.PESessionLockingStandardPipeline unlockSession
FINEST: IN UNLOCK_SESSION: sess = null
Aug 17, 2009 2:48:21 PM
com.sun.enterprise.security.web.GlassFishSingleSignOn invoke
FINE: Process request for '/v3test2cometd-java/cometd'
Aug 17, 2009 2:48:21 PM
com.sun.enterprise.security.web.GlassFishSingleSignOn invoke
FINE: Checking for SSO cookie
Aug 17, 2009 2:48:21 PM
com.sun.enterprise.security.web.GlassFishSingleSignOn invoke
FINE: SSO cookie is not present
Aug 17, 2009 2:48:21 PM
com.sun.enterprise.web.PESessionLockingStandardPipeline lockSession
FINEST: IN LOCK_SESSION: sess =null
Aug 17, 2009 2:48:21 PM com.sun.web.server.J2EEInstanceListener
instanceEvent
FINEST: *** InstanceEvent: BEFORE_SERVICE_EVENT
Aug 17, 2009 2:48:21 PM org.apache.catalina.core.ApplicationContext
log
INFO: PWC1412: WebModule[/v3test2cometd-java] ServletContext.log
():newTransport: client=10tqe6rtux0i2zokw,message={"id":
3,"connectionType":"long-polling","channel":"/meta/
connect","clientId":"10tqe6rtux0i2zokw"}
Aug 17, 2009 2:48:21 PM org.apache.catalina.core.ApplicationContext
log
INFO: PWC1412: WebModule[/v3test2cometd-java] ServletContext.log
():newTransport: result=org.cometd.server.JSONTransport@1fa2b3e
Aug 17, 2009 2:48:21 PM com.sun.web.server.J2EEInstanceListener
instanceEvent
FINEST: *** InstanceEvent: AFTER_SERVICE_EVENT
Aug 17, 2009 2:48:21 PM org.apache.catalina.core.StandardWrapperValve
log
SEVERE: StandardWrapperValve[cometd]: PWC1406: Servlet.service() for
servlet cometd threw exception
java.lang.IllegalStateException: Async not supported for this request
servlet cometd threw exception
at org.apache.catalina.connector.Request.startAsync(Request.java:
4056)
at org.apache.catalina.connector.Request.startAsync(Request.java:
3994)
at org.apache.catalina.connector.RequestFacade.startAsync
(RequestFacade.java:1032)
at org.eclipse.jetty.continuation.Servlet3Continuation.suspend
(Servlet3Continuation.java:138)
at org.cometd.server.continuation.ContinuationCometdServlet.service
(ContinuationCometdServlet.java:171)
at org.cometd.server.AbstractCometdServlet.service
(AbstractCometdServlet.java:250)
at org.apache.catalina.core.StandardWrapper.service
(StandardWrapper.java:1506)
at org.apache.catalina.core.StandardWrapperValve.invoke
(StandardWrapperValve.java:293)
at org.apache.catalina.core.StandardContextValve.invoke
(StandardContextValve.java:188)
at org.apache.catalina.core.StandardPipeline.invoke
(StandardPipeline.java:641)
at com.sun.enterprise.web.WebPipeline.invoke(WebPipeline.java:97)
at com.sun.enterprise.web.PESessionLockingStandardPipeline.invoke
(PESessionLockingStandardPipeline.java:85)
at org.apache.catalina.core.StandardHostValve.invoke
(StandardHostValve.java:185)
at org.apache.catalina.core.StandardPipeline.invoke
(StandardPipeline.java:641)
at org.apache.catalina.connector.CoyoteAdapter.doService
(CoyoteAdapter.java:338)
at org.apache.catalina.connector.CoyoteAdapter.service
(CoyoteAdapter.java:237)
at com.sun.enterprise.v3.services.impl.ContainerMapper.service
(ContainerMapper.java:202)
at com.sun.grizzly.http.ProcessorTask.invokeAdapter
(ProcessorTask.java:752)
at com.sun.grizzly.comet.CometEngine.executeServlet(CometEngine.java:
473)
at com.sun.grizzly.comet.CometEngine.handle(CometEngine.java:341)
at com.sun.grizzly.comet.CometAsyncFilter.doFilter
(CometAsyncFilter.java:84)
at com.sun.grizzly.arp.DefaultAsyncExecutor.invokeFilters
(DefaultAsyncExecutor.java:161)
at com.sun.grizzly.arp.DefaultAsyncExecutor.interrupt
(DefaultAsyncExecutor.java:137)
at com.sun.grizzly.arp.AsyncProcessorTask.doTask
(AsyncProcessorTask.java:88)
at com.sun.grizzly.http.TaskBase.run(TaskBase.java:189)
at com.sun.grizzly.util.FixedThreadPool$BasicWorker.dowork
(FixedThreadPool.java:379)
at com.sun.grizzly.util.FixedThreadPool$BasicWorker.run
(FixedThreadPool.java:360)
at java.lang.Thread.run(Thread.java:619)
Aug 17, 2009 2:48:21 PM
com.sun.enterprise.web.PESessionLockingStandardPipeline unlockSession
FINEST: IN UNLOCK_SESSION: sess = null
Clearly something to do with the continuations framework and
suspending a servlet request, beyond that I'm lost.
I'm running glassfish v3 promoted build b57 (from
http://download.java.net/glassfish/v3/promoted/), and the only jar
containing org.apache.cataline.connector.RequestFacade is glassfish/
modules/web-core.jar. I can't tell what release of the Catalina
libraries that is.
What is your feeling on this?
Cheers
Nick
neek
Aug 17, 2009, 10:32:19 PM8/17/09
to cometd-users
Success! Thanks to gregw for pointing the way to the light. I was
missing a ContinuationFilter init param that at least works around my
problem for now.
I find that even with the ContinuationFilter defined, I still need to
run a modified jetty-continuations.jar, because the "Servlet 3.0"
check fails and I still get the exception that started this thread.
So, when running on glassfish, you need to not only rebuilt jetty-
continuations.jar to fix the one-liner:
$ svn co http://dev.eclipse.org/svnroot/rt/org.eclipse.jetty/jetty/trunk
jetty-trunk
$ cd jetty-trunk
edit jetty-continuation/src/main/java/org/eclipse/jetty/continuation/
ContinuationSupport.java:
- s3cc=s3c.getConstructor(ServletRequest.class,
ServletResponse.class);
+ s3cc=s3c.getConstructor(ServletRequest.class);
$ mvn install
I found the maven build failed due to download.eclipse.org not
containing some jar's that are required, but I happen to have suitable
jars on my local drive, so made these changes to jetty-distribution/
pom.xml before 'mvn install' would complete:
- <get src="http://download.eclipse.org/tools/orbit/
downloads/drops/R20090529135407/bundles/
javax.servlet_2.5.0.v200806031605.jar"
+ <get src="file:///java/eclipse-3.5/plugins/
javax.servlet_2.5.0.v200806031605.jar"
- <get src="http://download.eclipse.org/tools/orbit/
downloads/drops/R20090529135407/bundles/
javax.activation_1.1.0.v200905021805.jar"
+ <get src="file:///java/eclipse-3.5/plugins/
javax.activation_1.1.0.v200905021805.jar"
- <get src="http://download.eclipse.org/tools/orbit/
downloads/drops/R20090529135407/bundles/
javax.mail_1.4.0.v200905040518.jar"
+ <get src="file:///java/eclipse-3.5/plugins/
javax.mail_1.4.0.v200905040518.jar"
Take the file jetty-distribution/target/distribution/lib/jetty-
continuation-7.0.0.RC4-SNAPSHOT.jar into your webapp environment.
Get and build cometd beta10 (or whatever) using suitable mvn build
from instructions at http://cometdproject.dojotoolkit.org/documentation/primer
(to build e.g. a jetty-7 dojo version), not the simplistic "mvn
install" given in the README. I built for jetty 7 and dojo. Extract
suitable bits to your glassfish project:
- cometd-api-1.0.0rc0-SNAPSHOT.jar
- cometd-java-server-1.0.0rc0-SNAPSHOT.jar
- the dojo source, including the updated files mentioned in the Primer
under "the non maven way"
Then include this init-param in your ContinuationFilter definition in
web.xml:
<init-param>
<param-name>faux</param-name>
<param-value>true</param-value>
</init-param>
This will, as I understand things, essentially turn off the benefit of
using Continuations, so the 'async' abilities of the servlets are not
used. However, my dojo js client now connects to the cometd servlet
in glassfish and can publish/subscribe OK.
Greg has mentioned they will be testing the real async version on
Glassfish, so this should be a temporary workaround.
Nick
missing a ContinuationFilter init param that at least works around my
problem for now.
I find that even with the ContinuationFilter defined, I still need to
run a modified jetty-continuations.jar, because the "Servlet 3.0"
check fails and I still get the exception that started this thread.
So, when running on glassfish, you need to not only rebuilt jetty-
continuations.jar to fix the one-liner:
$ svn co http://dev.eclipse.org/svnroot/rt/org.eclipse.jetty/jetty/trunk
jetty-trunk
$ cd jetty-trunk
edit jetty-continuation/src/main/java/org/eclipse/jetty/continuation/
ContinuationSupport.java:
- s3cc=s3c.getConstructor(ServletRequest.class,
ServletResponse.class);
+ s3cc=s3c.getConstructor(ServletRequest.class);
$ mvn install
I found the maven build failed due to download.eclipse.org not
containing some jar's that are required, but I happen to have suitable
jars on my local drive, so made these changes to jetty-distribution/
pom.xml before 'mvn install' would complete:
- <get src="http://download.eclipse.org/tools/orbit/
downloads/drops/R20090529135407/bundles/
javax.servlet_2.5.0.v200806031605.jar"
+ <get src="file:///java/eclipse-3.5/plugins/
javax.servlet_2.5.0.v200806031605.jar"
- <get src="http://download.eclipse.org/tools/orbit/
downloads/drops/R20090529135407/bundles/
javax.activation_1.1.0.v200905021805.jar"
+ <get src="file:///java/eclipse-3.5/plugins/
javax.activation_1.1.0.v200905021805.jar"
- <get src="http://download.eclipse.org/tools/orbit/
downloads/drops/R20090529135407/bundles/
javax.mail_1.4.0.v200905040518.jar"
+ <get src="file:///java/eclipse-3.5/plugins/
javax.mail_1.4.0.v200905040518.jar"
Take the file jetty-distribution/target/distribution/lib/jetty-
continuation-7.0.0.RC4-SNAPSHOT.jar into your webapp environment.
Get and build cometd beta10 (or whatever) using suitable mvn build
from instructions at http://cometdproject.dojotoolkit.org/documentation/primer
(to build e.g. a jetty-7 dojo version), not the simplistic "mvn
install" given in the README. I built for jetty 7 and dojo. Extract
suitable bits to your glassfish project:
- cometd-api-1.0.0rc0-SNAPSHOT.jar
- cometd-java-server-1.0.0rc0-SNAPSHOT.jar
- the dojo source, including the updated files mentioned in the Primer
under "the non maven way"
Then include this init-param in your ContinuationFilter definition in
web.xml:
<init-param>
<param-name>faux</param-name>
<param-value>true</param-value>
</init-param>
This will, as I understand things, essentially turn off the benefit of
using Continuations, so the 'async' abilities of the servlets are not
used. However, my dojo js client now connects to the cometd servlet
in glassfish and can publish/subscribe OK.
Greg has mentioned they will be testing the real async version on
Glassfish, so this should be a temporary workaround.
Nick
neek
Aug 27, 2009, 11:44:28 PM8/27/09
to cometd-users
Hi Simone and team,
I tried the 1.0.0rc0 release yesterday in Glassfish, and both the
Servlet 3.0 check fails, and the glassfish requirement to use
faux=true, seems to be present. Should I raise bugs at http://bugs.cometd.org,
or would you rather handle these issues yourselves?
By the way, the link to the Primer, just under the "Where to go next?"
heading on the documentation page, is broken : http://cometdproject.dojotoolkit.org/primer.
The link in the list, further down, works fine.
Cheers
Nick
I tried the 1.0.0rc0 release yesterday in Glassfish, and both the
Servlet 3.0 check fails, and the glassfish requirement to use
faux=true, seems to be present. Should I raise bugs at http://bugs.cometd.org,
or would you rather handle these issues yourselves?
By the way, the link to the Primer, just under the "Where to go next?"
heading on the documentation page, is broken : http://cometdproject.dojotoolkit.org/primer.
The link in the list, further down, works fine.
Cheers
Nick
Simone Bordet
Aug 28, 2009, 11:38:32 AM8/28/09
to cometd...@googlegroups.com
Hi,
On Fri, Aug 28, 2009 at 05:44, neek<neekf...@gmail.com> wrote:
>
> Hi Simone and team,
>
> I tried the 1.0.0rc0 release yesterday in Glassfish, and both the
> Servlet 3.0 check fails, and the glassfish requirement to use
> faux=true, seems to be present. Should I raise bugs at http://bugs.cometd.org,
> or would you rather handle these issues yourselves?
Raise the issue.
Please specify exact reproducible steps.
> By the way, the link to the Primer, just under the "Where to go next?"
> heading on the documentation page, is broken : http://cometdproject.dojotoolkit.org/primer.
Fixed, thanks.
Simon
--
http://bordet.blogspot.com
---
Finally, no matter how good the architecture and design are,
to deliver bug-free software with optimal performance and reliability,
the implementation technique must be flawless. Victoria Livschitz
alexb
Sep 3, 2009, 3:32:02 PM9/3/09
to cometd-users
Hi all!
I had exactly the same problem as neek but I wasn't using the
ContinuationFilter. I use glassfish 3 b62 and the latest 1.0.0rc1
snapshot of cometd with jquery. After including the filter all works
well... But can someone explain to me why I need the filter and is it
really just a workaround for gf 3 and can't we just use gf 3's servlet
3.0 implementation for async requests??? I also read this on jetty's
website:
Continuations will be replaced by standard Servlet-3.0 suspendable
requests once the specification is finalized. Any comments on that?
Alex
I had exactly the same problem as neek but I wasn't using the
ContinuationFilter. I use glassfish 3 b62 and the latest 1.0.0rc1
snapshot of cometd with jquery. After including the filter all works
well... But can someone explain to me why I need the filter and is it
really just a workaround for gf 3 and can't we just use gf 3's servlet
3.0 implementation for async requests??? I also read this on jetty's
website:
Continuations will be replaced by standard Servlet-3.0 suspendable
requests once the specification is finalized. Any comments on that?
Alex
> On Fri, Aug 28, 2009 at 05:44, neek<neekfenw...@gmail.com> wrote:
>
> > Hi Simone and team,
>
> > I tried the 1.0.0rc0 release yesterday in Glassfish, and both the
> > Servlet 3.0 check fails, and the glassfish requirement to use
> > faux=true, seems to be present. Should I raise bugs athttp://bugs.cometd.org,
>
> > Hi Simone and team,
>
> > I tried the 1.0.0rc0 release yesterday in Glassfish, and both the
> > Servlet 3.0 check fails, and the glassfish requirement to use
> > or would you rather handle these issues yourselves?
>
> Raise the issue.
> Please specify exact reproducible steps.
>
> > By the way, the link to the Primer, just under the "Where to go next?"
> > heading on the documentation page, is broken :http://cometdproject.dojotoolkit.org/primer.
>
> Fixed, thanks.
>
> Simon
> --http://bordet.blogspot.com
>
> Raise the issue.
> Please specify exact reproducible steps.
>
> > By the way, the link to the Primer, just under the "Where to go next?"
> > heading on the documentation page, is broken :http://cometdproject.dojotoolkit.org/primer.
>
> Fixed, thanks.
>
> Simon
alexb
Sep 6, 2009, 8:49:25 PM9/6/09
to neek, cometd...@googlegroups.com
After hours of messing around with jetty.continuation sources I came
to the same conclusions as neek - there is a bug (or is it
intentional?) in ContinuationSupport.java both in 7.0 branch and 8.
Anyway, after that you get async not supported errors so... I've put
<async-supported>true</async-supported> into pretty much every
<servlet></servlet> and <filter> elements in web.xml. This makes them
all support async (no idea as to why it's not by default!?!?). And...
voila it works! :) No need for ContinuationFilter anymore so remove it
completely. I hope this is helpful to you, neek.
to the same conclusions as neek - there is a bug (or is it
intentional?) in ContinuationSupport.java both in 7.0 branch and 8.
Anyway, after that you get async not supported errors so... I've put
<async-supported>true</async-supported> into pretty much every
<servlet></servlet> and <filter> elements in web.xml. This makes them
all support async (no idea as to why it's not by default!?!?). And...
voila it works! :) No need for ContinuationFilter anymore so remove it
completely. I hope this is helpful to you, neek.
Alex
On Aug 28, 6:44 am, neek <neekfenw...@gmail.com> wrote:
> Hi Simone and team,
>
> I tried the 1.0.0rc0 release yesterday in Glassfish, and both the
> Servlet 3.0 check fails, and the glassfish requirement to use
> faux=true, seems to be present. Should I raise bugs athttp://bugs.cometd.org,
Reply all
Reply to author
Forward
0 new messages