Can't get rid of the BlockIOCometSupport fallback in Tomcat

classic Classic list List threaded Threaded
15 messages Options
Reply | Threaded
Open this post in threaded view
|

Can't get rid of the BlockIOCometSupport fallback in Tomcat

Mark H
Hi everyone,

I know this issue has been raised a couple times already, so sorry for
reposting it. I can't figure out how to resolve this even after reading
through pretty much anything I've found on the issue.

The problem is the following warning in my server's log file:

2011-09-16 12:00:36,623 [http-8080-exec-1] WARN
org.atmosphere.cpr.AtmosphereServlet - failed using comet support:
org.atmosphere.container.TomcatCometSupport, error: Tomcat failed to
detect this is a Comet application because context.xml is missing or
the Http11NioProtocol Connector is not enabled.
If that's not the case, you can also remove META-INF/context.xml and
WEB-INF/lib/atmosphere-compat-tomcat.jar
2011-09-16 12:00:36,625 [http-8080-exec-1] WARN
org.atmosphere.cpr.AtmosphereServlet - Using BlockingIOCometSupport.

I am using version 0.7.1 of Atmosphere in combination with the Guice
integration module (atmosphere-guice) as well as the Google Web Toolkit
(GWT) integration (atmosphere-gwt-common, atmosphere-gwt-client,
atmosphere-gwt-server, atmosphere-gwt-poll). There are also the
atmosphere-runtime (obviously), the atmosphere-jersey and the
atmosphere-annotations JARs on my classpath but they shouldn't be in
use (except by Atmosphere internally).

What have I done so far:

0) I have tried getting it to work on Tomcat 7 (v7.0.21) and Tomcat 6
(v6.0.33); on Tomcat 7 I also can't get it to use Servlet 3.0 (maybe
because GWT requires me to specify the web module to be a version 2.5
module)
1) I have enabled the Http11NioProtocol Connnector in my Tomcat
server.xml configuration.
2) I have removed the "atmosphere-compat-tomcat-0.7.1.jar" from
WEB-INF/lib since it contains fake classes only. (this only works for
Tomcat 6 since Tomcat 7 requires the fake classes from the JAR because
it appears that the namespaces for Tomcat's Comet types have changed)
3) I have tried removing the META-INF/context.xml to no avail.
4) I have tried adding <Loader delegate="true"/> to
META-INF/context.xml

I think my issue has to do with the fact that I am using the Guice
integration (or the GWT integration).

The only thread I've found/read that deals with resolving something
similar is this one:
http://atmosphere-users-mailling-list.2493822.n2.nabble.com/New-Guice-i
ntegration-always-uses-blocking-IO-on-Tomcat-td4469089.html

I've noticed that the fix proposed there is included in the
AtmosphereGuiceServlet class as well as the
GuiceManagedAtmosphereServlet class. The code in the method
detectSupportedFramework() is however never called in my case since I
supply an atmosphere.xml that defines one dummy handler that I
programmatically remove before programmatically adding my own handler
(I do this adding of the atmosphere handler programmatically because
the handler itself is constructed by Guice since it depends on some
other application classes that are injected to its constructor; if I
don't do it this way, it blows up at creation time since the handler
does not define a default constructor). Could this be somehow related
to my problem? (Sorry, I've been getting slightly confused over the
past 3 hours)

Does anyone have any additional hints what I could try in order to
activate the non-blocking support for Tomcat?

Would greatly appreciate any help, thanks a lot!

- Mark
Reply | Threaded
Open this post in threaded view
|

[atmosphere-users] Re: Can't get rid of the BlockIOCometSupport fallback in Tomcat

Pierre Goupil
+1. I'm looking forward for responses to this post! :-)



On Fri, Sep 16, 2011 at 12:49 PM, <[hidden email]> wrote:
Hi everyone,

I know this issue has been raised a couple times already, so sorry for
reposting it. I can't figure out how to resolve this even after reading
through pretty much anything I've found on the issue.

The problem is the following warning in my server's log file:

2011-09-16 12:00:36,623 [http-8080-exec-1] WARN
org.atmosphere.cpr.AtmosphereServlet - failed using comet support:
org.atmosphere.container.TomcatCometSupport, error: Tomcat failed to
detect this is a Comet application because context.xml is missing or
the Http11NioProtocol Connector is not enabled.
If that's not the case, you can also remove META-INF/context.xml and
WEB-INF/lib/atmosphere-compat-tomcat.jar
2011-09-16 12:00:36,625 [http-8080-exec-1] WARN
org.atmosphere.cpr.AtmosphereServlet - Using BlockingIOCometSupport.

I am using version 0.7.1 of Atmosphere in combination with the Guice
integration module (atmosphere-guice) as well as the Google Web Toolkit
(GWT) integration (atmosphere-gwt-common, atmosphere-gwt-client,
atmosphere-gwt-server, atmosphere-gwt-poll). There are also the
atmosphere-runtime (obviously), the atmosphere-jersey and the
atmosphere-annotations JARs on my classpath but they shouldn't be in
use (except by Atmosphere internally).

What have I done so far:

0) I have tried getting it to work on Tomcat 7 (v7.0.21) and Tomcat 6
(v6.0.33); on Tomcat 7 I also can't get it to use Servlet 3.0 (maybe
because GWT requires me to specify the web module to be a version 2.5
module)
1) I have enabled the Http11NioProtocol Connnector in my Tomcat
server.xml configuration.
2) I have removed the "atmosphere-compat-tomcat-0.7.1.jar" from
WEB-INF/lib since it contains fake classes only. (this only works for
Tomcat 6 since Tomcat 7 requires the fake classes from the JAR because
it appears that the namespaces for Tomcat's Comet types have changed)
3) I have tried removing the META-INF/context.xml to no avail.
4) I have tried adding <Loader delegate="true"/> to
META-INF/context.xml

I think my issue has to do with the fact that I am using the Guice
integration (or the GWT integration).

The only thread I've found/read that deals with resolving something
similar is this one:
http://atmosphere-users-mailling-list.2493822.n2.nabble.com/New-Guice-i
ntegration-always-uses-blocking-IO-on-Tomcat-td4469089.html


I've noticed that the fix proposed there is included in the
AtmosphereGuiceServlet class as well as the
GuiceManagedAtmosphereServlet class. The code in the method
detectSupportedFramework() is however never called in my case since I
supply an atmosphere.xml that defines one dummy handler that I
programmatically remove before programmatically adding my own handler
(I do this adding of the atmosphere handler programmatically because
the handler itself is constructed by Guice since it depends on some
other application classes that are injected to its constructor; if I
don't do it this way, it blows up at creation time since the handler
does not define a default constructor). Could this be somehow related
to my problem? (Sorry, I've been getting slightly confused over the
past 3 hours)

Does anyone have any additional hints what I could try in order to
activate the non-blocking support for Tomcat?

Would greatly appreciate any help, thanks a lot!

- Mark
Reply | Threaded
Open this post in threaded view
|

Re: Can't get rid of the BlockIOCometSupport fallback in Tomcat

Mark H
In reply to this post by Mark H
Little update,

I was now able to get TomcatCometSupport used (instead of fallback BlockingIOCometSupport) in Tomcat 6. I rewrote a portion of my application and basically removed my Atmosphere servlet from the servlets that are managed by the Guice servlet extension (the ones that are bound in the Guice module via serve(...).with(ServletClass.class);).

Unfortunately I loose the session-scoped objects feature of Guice and I need to manually map my Atmosphere servlet in the web.xml file but so far it's working correctly and I think I can work around this lack of features. My Atmosphere servlet now injects itself by grabbing the Guice injector from the ServletContext (just like in AtmosphereGuiceServlet class) and retrieving whatever it needs from it (in my case one singleton).

When I deploy this into Tomcat 7 I get ClassDefNotFoundExceptions for the Comet interface, since the Tomcat team has changed the namespaces for those types as far as I know. What I'd like to know is when the Tomcat7CometSupport implementation will become publicly available? I think it's not in the current stable version (0.7.2) and I would like to rather not depend on snapshots :-). I can't use the Servlet 3.0 API because my web application must be a Servlet 2.5 module (because of GWT).

Big question at the end would be: Is there any way to deploy a CometProcessor implementor (such as the AtmosphereServlet) inside Tomcat that's managed by Guice (with guice-servlet extension)? Because if not I kind of think that Atmosphere's Guice integration is obsolete, or am I not seeing things clearly there?

Cheers,
Mark

----- Ursprüngliche Mail -----
Von: [hidden email]
An: [hidden email]
Gesendet: Freitag, 16. September 2011 12:49:23
Betreff: Can't get rid of the BlockIOCometSupport fallback in Tomcat

Hi everyone,

I know this issue has been raised a couple times already, so sorry for
reposting it. I can't figure out how to resolve this even after reading
through pretty much anything I've found on the issue.

The problem is the following warning in my server's log file:

2011-09-16 12:00:36,623 [http-8080-exec-1] WARN
org.atmosphere.cpr.AtmosphereServlet - failed using comet support:
org.atmosphere.container.TomcatCometSupport, error: Tomcat failed to
detect this is a Comet application because context.xml is missing or
the Http11NioProtocol Connector is not enabled.
If that's not the case, you can also remove META-INF/context.xml and
WEB-INF/lib/atmosphere-compat-tomcat.jar
2011-09-16 12:00:36,625 [http-8080-exec-1] WARN
org.atmosphere.cpr.AtmosphereServlet - Using BlockingIOCometSupport.

I am using version 0.7.1 of Atmosphere in combination with the Guice
integration module (atmosphere-guice) as well as the Google Web Toolkit
(GWT) integration (atmosphere-gwt-common, atmosphere-gwt-client,
atmosphere-gwt-server, atmosphere-gwt-poll). There are also the
atmosphere-runtime (obviously), the atmosphere-jersey and the
atmosphere-annotations JARs on my classpath but they shouldn't be in
use (except by Atmosphere internally).

What have I done so far:

0) I have tried getting it to work on Tomcat 7 (v7.0.21) and Tomcat 6
(v6.0.33); on Tomcat 7 I also can't get it to use Servlet 3.0 (maybe
because GWT requires me to specify the web module to be a version 2.5
module)
1) I have enabled the Http11NioProtocol Connnector in my Tomcat
server.xml configuration.
2) I have removed the "atmosphere-compat-tomcat-0.7.1.jar" from
WEB-INF/lib since it contains fake classes only. (this only works for
Tomcat 6 since Tomcat 7 requires the fake classes from the JAR because
it appears that the namespaces for Tomcat's Comet types have changed)
3) I have tried removing the META-INF/context.xml to no avail.
4) I have tried adding <Loader delegate="true"/> to
META-INF/context.xml

I think my issue has to do with the fact that I am using the Guice
integration (or the GWT integration).

The only thread I've found/read that deals with resolving something
similar is this one:
http://atmosphere-users-mailling-list.2493822.n2.nabble.com/New-Guice-i
ntegration-always-uses-blocking-IO-on-Tomcat-td4469089.html

I've noticed that the fix proposed there is included in the
AtmosphereGuiceServlet class as well as the
GuiceManagedAtmosphereServlet class. The code in the method
detectSupportedFramework() is however never called in my case since I
supply an atmosphere.xml that defines one dummy handler that I
programmatically remove before programmatically adding my own handler
(I do this adding of the atmosphere handler programmatically because
the handler itself is constructed by Guice since it depends on some
other application classes that are injected to its constructor; if I
don't do it this way, it blows up at creation time since the handler
does not define a default constructor). Could this be somehow related
to my problem? (Sorry, I've been getting slightly confused over the
past 3 hours)

Does anyone have any additional hints what I could try in order to
activate the non-blocking support for Tomcat?

Would greatly appreciate any help, thanks a lot!

- Mark
Reply | Threaded
Open this post in threaded view
|

[[atmosphere-users]] Re: Can't get rid of the BlockIOCometSupport fallback in Tomcat

Jeanfrancois Arcand-4
Salut,

can you try with atmosphere 0.8? I did fix the Tomcat 7 class namespace
changes. If that doesn't work can you send me a test case privately? I
will take a look and see what's happening.

Thanks!

-- Jeanfrancois

On 11-09-16 7:45 AM, Mark Heimann wrote:

> Little update,
>
> I was now able to get TomcatCometSupport used (instead of fallback BlockingIOCometSupport) in Tomcat 6. I rewrote a portion of my application and basically removed my Atmosphere servlet from the servlets that are managed by the Guice servlet extension (the ones that are bound in the Guice module via serve(...).with(ServletClass.class);).
>
> Unfortunately I loose the session-scoped objects feature of Guice and I need to manually map my Atmosphere servlet in the web.xml file but so far it's working correctly and I think I can work around this lack of features. My Atmosphere servlet now injects itself by grabbing the Guice injector from the ServletContext (just like in AtmosphereGuiceServlet class) and retrieving whatever it needs from it (in my case one singleton).
>
> When I deploy this into Tomcat 7 I get ClassDefNotFoundExceptions for the Comet interface, since the Tomcat team has changed the namespaces for those types as far as I know. What I'd like to know is when the Tomcat7CometSupport implementation will become publicly available? I think it's not in the current stable version (0.7.2) and I would like to rather not depend on snapshots :-). I can't use the Servlet 3.0 API because my web application must be a Servlet 2.5 module (because of GWT).
>
> Big question at the end would be: Is there any way to deploy a CometProcessor implementor (such as the AtmosphereServlet) inside Tomcat that's managed by Guice (with guice-servlet extension)? Because if not I kind of think that Atmosphere's Guice integration is obsolete, or am I not seeing things clearly there?
>
> Cheers,
> Mark
>
> ----- Ursprüngliche Mail -----
> Von: [hidden email]
> An: [hidden email]
> Gesendet: Freitag, 16. September 2011 12:49:23
> Betreff: Can't get rid of the BlockIOCometSupport fallback in Tomcat
>
> Hi everyone,
>
> I know this issue has been raised a couple times already, so sorry for
> reposting it. I can't figure out how to resolve this even after reading
> through pretty much anything I've found on the issue.
>
> The problem is the following warning in my server's log file:
>
> 2011-09-16 12:00:36,623 [http-8080-exec-1] WARN
> org.atmosphere.cpr.AtmosphereServlet - failed using comet support:
> org.atmosphere.container.TomcatCometSupport, error: Tomcat failed to
> detect this is a Comet application because context.xml is missing or
> the Http11NioProtocol Connector is not enabled.
> If that's not the case, you can also remove META-INF/context.xml and
> WEB-INF/lib/atmosphere-compat-tomcat.jar
> 2011-09-16 12:00:36,625 [http-8080-exec-1] WARN
> org.atmosphere.cpr.AtmosphereServlet - Using BlockingIOCometSupport.
>
> I am using version 0.7.1 of Atmosphere in combination with the Guice
> integration module (atmosphere-guice) as well as the Google Web Toolkit
> (GWT) integration (atmosphere-gwt-common, atmosphere-gwt-client,
> atmosphere-gwt-server, atmosphere-gwt-poll). There are also the
> atmosphere-runtime (obviously), the atmosphere-jersey and the
> atmosphere-annotations JARs on my classpath but they shouldn't be in
> use (except by Atmosphere internally).
>
> What have I done so far:
>
> 0) I have tried getting it to work on Tomcat 7 (v7.0.21) and Tomcat 6
> (v6.0.33); on Tomcat 7 I also can't get it to use Servlet 3.0 (maybe
> because GWT requires me to specify the web module to be a version 2.5
> module)
> 1) I have enabled the Http11NioProtocol Connnector in my Tomcat
> server.xml configuration.
> 2) I have removed the "atmosphere-compat-tomcat-0.7.1.jar" from
> WEB-INF/lib since it contains fake classes only. (this only works for
> Tomcat 6 since Tomcat 7 requires the fake classes from the JAR because
> it appears that the namespaces for Tomcat's Comet types have changed)
> 3) I have tried removing the META-INF/context.xml to no avail.
> 4) I have tried adding<Loader delegate="true"/>  to
> META-INF/context.xml
>
> I think my issue has to do with the fact that I am using the Guice
> integration (or the GWT integration).
>
> The only thread I've found/read that deals with resolving something
> similar is this one:
> http://atmosphere-users-mailling-list.2493822.n2.nabble.com/New-Guice-i
> ntegration-always-uses-blocking-IO-on-Tomcat-td4469089.html
>
> I've noticed that the fix proposed there is included in the
> AtmosphereGuiceServlet class as well as the
> GuiceManagedAtmosphereServlet class. The code in the method
> detectSupportedFramework() is however never called in my case since I
> supply an atmosphere.xml that defines one dummy handler that I
> programmatically remove before programmatically adding my own handler
> (I do this adding of the atmosphere handler programmatically because
> the handler itself is constructed by Guice since it depends on some
> other application classes that are injected to its constructor; if I
> don't do it this way, it blows up at creation time since the handler
> does not define a default constructor). Could this be somehow related
> to my problem? (Sorry, I've been getting slightly confused over the
> past 3 hours)
>
> Does anyone have any additional hints what I could try in order to
> activate the non-blocking support for Tomcat?
>
> Would greatly appreciate any help, thanks a lot!
>
> - Mark
Reply | Threaded
Open this post in threaded view
|

[atmosphere-users] Re: Can't get rid of the BlockIOCometSupport fallback in Tomcat

java.net
In reply to this post by Mark H
Hi

On 16-9-2011 16:45, Mark Heimann wrote:
> I can't use the Servlet 3.0 API because my web application must be a Servlet 2.5 module (because of GWT).

We use GWT in our application and we make use of GWT RPC and
atmosphere-gwt with Servlet 3.0 on Glassfish. Why do you think you
cannot use Servlet 3.0 with GWT?

Pierre

Reply | Threaded
Open this post in threaded view
|

[atmosphere-users] Re: Can't get rid of the BlockIOCometSupport fallback in Tomcat

Mark H
Hi,

we have started developing the application with Servlet 2.5 because Tomcat 7 was not available at that time. I just remember having problems when switching to a Servlet 3.0 configuration in Eclipse; I could try it out again I guess.

So what I meant is that our application is a version 2.5 web module and therefore we cannot use Servlet 3.0 features (such as all the async goodness) and have to use the Tomcat-specific features.

I am wondering whether you are actually hosting your GWT services inside a servlet that uses the AsyncContext for example, because as far as I know the RemoteServiceServlet and RpcServlet (for deRPC mechanism) classes of GWT don't use any of this. I guess you'd have to extend those classes or provide a drop-in replacement for them.

But anyways, we don't need to manually suspend requests in a GWT service for our app. It's just not working with Servlet 3.0 in our case because our web module is version 2.5 :-). It should use the CometProcessor interfaces of Tomcat but it doesn't work when you are serving everything through a Guice filter as we did (because Tomcat is apparently not intelligent enough to identify the AtmosphereGwtServlet as a CometProcessor and does not correctly do it's magic with the HttpRervletRequest objects). Now, I'm mapping the Atmosphere servlet directly in the web.xml and it's then correctly working (no BlockionIOCometSupport calls :-)) -- the whole code just got a bit uglier for my taste.

Cheers,
Mark

----- Ursprüngliche Mail -----
Von: "java net" <[hidden email]>
An: [hidden email]
Gesendet: Montag, 19. September 2011 10:27:34
Betreff: [atmosphere-users] Re: Can't get rid of the BlockIOCometSupport fallback in Tomcat

Hi

On 16-9-2011 16:45, Mark Heimann wrote:
> I can't use the Servlet 3.0 API because my web application must be a Servlet 2.5 module (because of GWT).

We use GWT in our application and we make use of GWT RPC and
atmosphere-gwt with Servlet 3.0 on Glassfish. Why do you think you
cannot use Servlet 3.0 with GWT?

Pierre

Reply | Threaded
Open this post in threaded view
|

[atmosphere-users] Re: [] Re: Can't get rid of the BlockIOCometSupport fallback in Tomcat

Mark H
In reply to this post by Jeanfrancois Arcand-4
Hi there,

thanks for the quick response. I will try it out with the 0.8-SNAPSHOT version as soon as I can and tell you if it's deployable within Tomcat 7 without the ClassDefNotFound errors.

Just one quick question: From the top of your head, do you know whether there is any way to have Tomcat see the Atmosphere servlet as a CometProcessor when I am configuring it with Guice (i.e. not explicitly putting it into the web.xml file)?

Thanks a lot,

Mark

----- Ursprüngliche Mail -----
Von: "Jeanfrancois Arcand" <[hidden email]>
An: [hidden email]
Gesendet: Montag, 19. September 2011 01:54:47
Betreff: [[atmosphere-users]] Re: Can't get rid of the BlockIOCometSupport fallback in Tomcat

Salut,

can you try with atmosphere 0.8? I did fix the Tomcat 7 class namespace
changes. If that doesn't work can you send me a test case privately? I
will take a look and see what's happening.

Thanks!

-- Jeanfrancois

On 11-09-16 7:45 AM, Mark Heimann wrote:

> Little update,
>
> I was now able to get TomcatCometSupport used (instead of fallback BlockingIOCometSupport) in Tomcat 6. I rewrote a portion of my application and basically removed my Atmosphere servlet from the servlets that are managed by the Guice servlet extension (the ones that are bound in the Guice module via serve(...).with(ServletClass.class);).
>
> Unfortunately I loose the session-scoped objects feature of Guice and I need to manually map my Atmosphere servlet in the web.xml file but so far it's working correctly and I think I can work around this lack of features. My Atmosphere servlet now injects itself by grabbing the Guice injector from the ServletContext (just like in AtmosphereGuiceServlet class) and retrieving whatever it needs from it (in my case one singleton).
>
> When I deploy this into Tomcat 7 I get ClassDefNotFoundExceptions for the Comet interface, since the Tomcat team has changed the namespaces for those types as far as I know. What I'd like to know is when the Tomcat7CometSupport implementation will become publicly available? I think it's not in the current stable version (0.7.2) and I would like to rather not depend on snapshots :-). I can't use the Servlet 3.0 API because my web application must be a Servlet 2.5 module (because of GWT).
>
> Big question at the end would be: Is there any way to deploy a CometProcessor implementor (such as the AtmosphereServlet) inside Tomcat that's managed by Guice (with guice-servlet extension)? Because if not I kind of think that Atmosphere's Guice integration is obsolete, or am I not seeing things clearly there?
>
> Cheers,
> Mark
>
> ----- Ursprüngliche Mail -----
> Von: [hidden email]
> An: [hidden email]
> Gesendet: Freitag, 16. September 2011 12:49:23
> Betreff: Can't get rid of the BlockIOCometSupport fallback in Tomcat
>
> Hi everyone,
>
> I know this issue has been raised a couple times already, so sorry for
> reposting it. I can't figure out how to resolve this even after reading
> through pretty much anything I've found on the issue.
>
> The problem is the following warning in my server's log file:
>
> 2011-09-16 12:00:36,623 [http-8080-exec-1] WARN
> org.atmosphere.cpr.AtmosphereServlet - failed using comet support:
> org.atmosphere.container.TomcatCometSupport, error: Tomcat failed to
> detect this is a Comet application because context.xml is missing or
> the Http11NioProtocol Connector is not enabled.
> If that's not the case, you can also remove META-INF/context.xml and
> WEB-INF/lib/atmosphere-compat-tomcat.jar
> 2011-09-16 12:00:36,625 [http-8080-exec-1] WARN
> org.atmosphere.cpr.AtmosphereServlet - Using BlockingIOCometSupport.
>
> I am using version 0.7.1 of Atmosphere in combination with the Guice
> integration module (atmosphere-guice) as well as the Google Web Toolkit
> (GWT) integration (atmosphere-gwt-common, atmosphere-gwt-client,
> atmosphere-gwt-server, atmosphere-gwt-poll). There are also the
> atmosphere-runtime (obviously), the atmosphere-jersey and the
> atmosphere-annotations JARs on my classpath but they shouldn't be in
> use (except by Atmosphere internally).
>
> What have I done so far:
>
> 0) I have tried getting it to work on Tomcat 7 (v7.0.21) and Tomcat 6
> (v6.0.33); on Tomcat 7 I also can't get it to use Servlet 3.0 (maybe
> because GWT requires me to specify the web module to be a version 2.5
> module)
> 1) I have enabled the Http11NioProtocol Connnector in my Tomcat
> server.xml configuration.
> 2) I have removed the "atmosphere-compat-tomcat-0.7.1.jar" from
> WEB-INF/lib since it contains fake classes only. (this only works for
> Tomcat 6 since Tomcat 7 requires the fake classes from the JAR because
> it appears that the namespaces for Tomcat's Comet types have changed)
> 3) I have tried removing the META-INF/context.xml to no avail.
> 4) I have tried adding<Loader delegate="true"/>  to
> META-INF/context.xml
>
> I think my issue has to do with the fact that I am using the Guice
> integration (or the GWT integration).
>
> The only thread I've found/read that deals with resolving something
> similar is this one:
> http://atmosphere-users-mailling-list.2493822.n2.nabble.com/New-Guice-i
> ntegration-always-uses-blocking-IO-on-Tomcat-td4469089.html
>
> I've noticed that the fix proposed there is included in the
> AtmosphereGuiceServlet class as well as the
> GuiceManagedAtmosphereServlet class. The code in the method
> detectSupportedFramework() is however never called in my case since I
> supply an atmosphere.xml that defines one dummy handler that I
> programmatically remove before programmatically adding my own handler
> (I do this adding of the atmosphere handler programmatically because
> the handler itself is constructed by Guice since it depends on some
> other application classes that are injected to its constructor; if I
> don't do it this way, it blows up at creation time since the handler
> does not define a default constructor). Could this be somehow related
> to my problem? (Sorry, I've been getting slightly confused over the
> past 3 hours)
>
> Does anyone have any additional hints what I could try in order to
> activate the non-blocking support for Tomcat?
>
> Would greatly appreciate any help, thanks a lot!
>
> - Mark
Reply | Threaded
Open this post in threaded view
|

[atmosphere-users] Re: [] Re: Can't get rid of the BlockIOCometSupport fallback in Tomcat

Jeanfrancois Arcand-4
Salut,

I don't think this is doable...like you observed, Tomcat doesn't like
seeing filter that aren't implementing the CometProcessor stuff and will
never enable the async stuff because of that (ya that sucks I know). The
only solution for you would be to use a Servlet 3.0 container (but I
have read your explanation). But until you go into production you may
"live" with the blocking I/O stuff I would say.

A+

-- Jeanfrancois

On 11-09-19 4:36 AM, Mark Heimann wrote:

> Hi there,
>
> thanks for the quick response. I will try it out with the 0.8-SNAPSHOT version as soon as I can and tell you if it's deployable within Tomcat 7 without the ClassDefNotFound errors.
>
> Just one quick question: From the top of your head, do you know whether there is any way to have Tomcat see the Atmosphere servlet as a CometProcessor when I am configuring it with Guice (i.e. not explicitly putting it into the web.xml file)?
>
> Thanks a lot,
>
> Mark
>
> ----- Ursprüngliche Mail -----
> Von: "Jeanfrancois Arcand"<[hidden email]>
> An: [hidden email]
> Gesendet: Montag, 19. September 2011 01:54:47
> Betreff: [[atmosphere-users]] Re: Can't get rid of the BlockIOCometSupport fallback in Tomcat
>
> Salut,
>
> can you try with atmosphere 0.8? I did fix the Tomcat 7 class namespace
> changes. If that doesn't work can you send me a test case privately? I
> will take a look and see what's happening.
>
> Thanks!
>
> -- Jeanfrancois
>
> On 11-09-16 7:45 AM, Mark Heimann wrote:
>> Little update,
>>
>> I was now able to get TomcatCometSupport used (instead of fallback BlockingIOCometSupport) in Tomcat 6. I rewrote a portion of my application and basically removed my Atmosphere servlet from the servlets that are managed by the Guice servlet extension (the ones that are bound in the Guice module via serve(...).with(ServletClass.class);).
>>
>> Unfortunately I loose the session-scoped objects feature of Guice and I need to manually map my Atmosphere servlet in the web.xml file but so far it's working correctly and I think I can work around this lack of features. My Atmosphere servlet now injects itself by grabbing the Guice injector from the ServletContext (just like in AtmosphereGuiceServlet class) and retrieving whatever it needs from it (in my case one singleton).
>>
>> When I deploy this into Tomcat 7 I get ClassDefNotFoundExceptions for the Comet interface, since the Tomcat team has changed the namespaces for those types as far as I know. What I'd like to know is when the Tomcat7CometSupport implementation will become publicly available? I think it's not in the current stable version (0.7.2) and I would like to rather not depend on snapshots :-). I can't use the Servlet 3.0 API because my web application must be a Servlet 2.5 module (because of GWT).
>>
>> Big question at the end would be: Is there any way to deploy a CometProcessor implementor (such as the AtmosphereServlet) inside Tomcat that's managed by Guice (with guice-servlet extension)? Because if not I kind of think that Atmosphere's Guice integration is obsolete, or am I not seeing things clearly there?
>>
>> Cheers,
>> Mark
>>
>> ----- Ursprüngliche Mail -----
>> Von: [hidden email]
>> An: [hidden email]
>> Gesendet: Freitag, 16. September 2011 12:49:23
>> Betreff: Can't get rid of the BlockIOCometSupport fallback in Tomcat
>>
>> Hi everyone,
>>
>> I know this issue has been raised a couple times already, so sorry for
>> reposting it. I can't figure out how to resolve this even after reading
>> through pretty much anything I've found on the issue.
>>
>> The problem is the following warning in my server's log file:
>>
>> 2011-09-16 12:00:36,623 [http-8080-exec-1] WARN
>> org.atmosphere.cpr.AtmosphereServlet - failed using comet support:
>> org.atmosphere.container.TomcatCometSupport, error: Tomcat failed to
>> detect this is a Comet application because context.xml is missing or
>> the Http11NioProtocol Connector is not enabled.
>> If that's not the case, you can also remove META-INF/context.xml and
>> WEB-INF/lib/atmosphere-compat-tomcat.jar
>> 2011-09-16 12:00:36,625 [http-8080-exec-1] WARN
>> org.atmosphere.cpr.AtmosphereServlet - Using BlockingIOCometSupport.
>>
>> I am using version 0.7.1 of Atmosphere in combination with the Guice
>> integration module (atmosphere-guice) as well as the Google Web Toolkit
>> (GWT) integration (atmosphere-gwt-common, atmosphere-gwt-client,
>> atmosphere-gwt-server, atmosphere-gwt-poll). There are also the
>> atmosphere-runtime (obviously), the atmosphere-jersey and the
>> atmosphere-annotations JARs on my classpath but they shouldn't be in
>> use (except by Atmosphere internally).
>>
>> What have I done so far:
>>
>> 0) I have tried getting it to work on Tomcat 7 (v7.0.21) and Tomcat 6
>> (v6.0.33); on Tomcat 7 I also can't get it to use Servlet 3.0 (maybe
>> because GWT requires me to specify the web module to be a version 2.5
>> module)
>> 1) I have enabled the Http11NioProtocol Connnector in my Tomcat
>> server.xml configuration.
>> 2) I have removed the "atmosphere-compat-tomcat-0.7.1.jar" from
>> WEB-INF/lib since it contains fake classes only. (this only works for
>> Tomcat 6 since Tomcat 7 requires the fake classes from the JAR because
>> it appears that the namespaces for Tomcat's Comet types have changed)
>> 3) I have tried removing the META-INF/context.xml to no avail.
>> 4) I have tried adding<Loader delegate="true"/>   to
>> META-INF/context.xml
>>
>> I think my issue has to do with the fact that I am using the Guice
>> integration (or the GWT integration).
>>
>> The only thread I've found/read that deals with resolving something
>> similar is this one:
>> http://atmosphere-users-mailling-list.2493822.n2.nabble.com/New-Guice-i
>> ntegration-always-uses-blocking-IO-on-Tomcat-td4469089.html
>>
>> I've noticed that the fix proposed there is included in the
>> AtmosphereGuiceServlet class as well as the
>> GuiceManagedAtmosphereServlet class. The code in the method
>> detectSupportedFramework() is however never called in my case since I
>> supply an atmosphere.xml that defines one dummy handler that I
>> programmatically remove before programmatically adding my own handler
>> (I do this adding of the atmosphere handler programmatically because
>> the handler itself is constructed by Guice since it depends on some
>> other application classes that are injected to its constructor; if I
>> don't do it this way, it blows up at creation time since the handler
>> does not define a default constructor). Could this be somehow related
>> to my problem? (Sorry, I've been getting slightly confused over the
>> past 3 hours)
>>
>> Does anyone have any additional hints what I could try in order to
>> activate the non-blocking support for Tomcat?
>>
>> Would greatly appreciate any help, thanks a lot!
>>
>> - Mark
Reply | Threaded
Open this post in threaded view
|

[atmosphere-users] Re: [] Re: Can't get rid of the BlockIOCometSupport fallback in Tomcat

Mark H
Hi,

just checked with 0.8-SNAPSHOT from the http://oss.sonatype.org/content/repositories/snapshots/ repository. I can't get the GWT compiler step working, looks like the serialization code is incompatible with my GWT version (2.2.0).

I get the following stack trace during the mentioned compilation step:

[INFO] Compiling module XXXXXXX
[INFO]    [ERROR] Errors in 'file:/XXXXXX'
[INFO]       [ERROR]  Internal compiler error
[INFO] java.lang.NoSuchMethodError: com.google.gwt.user.rebind.rpc.SerializableTypeOracleBuilder.<init>(Lcom/google/gwt/core/ext/TreeLogger;Lcom/google/gwt/core/ext/PropertyOracle;Lcom/google/gwt/core/ext/GeneratorContextExt;)V
[INFO] at org.atmosphere.gwt.rebind.SerializerGenerator.generateIncrementally(SerializerGenerator.java:86)
[INFO] at com.google.gwt.dev.javac.StandardGeneratorContext.runGeneratorIncrementally(StandardGeneratorContext.java:662)
[INFO] at com.google.gwt.dev.cfg.RuleGenerateWith.realize(RuleGenerateWith.java:41)
[INFO] at com.google.gwt.dev.shell.StandardRebindOracle$Rebinder.rebind(StandardRebindOracle.java:74)
[INFO] at com.google.gwt.dev.shell.StandardRebindOracle.rebind(StandardRebindOracle.java:259)
[INFO] at com.google.gwt.dev.shell.StandardRebindOracle.rebind(StandardRebindOracle.java:248)
[INFO] at com.google.gwt.dev.DistillerRebindPermutationOracle.getAllPossibleRebindAnswers(DistillerRebindPermutationOracle.java:91)
[INFO] at com.google.gwt.dev.jdt.WebModeCompilerFrontEnd.doFindAdditionalTypesUsingRebinds(WebModeCompilerFrontEnd.java:106)
[INFO] at com.google.gwt.dev.jdt.AbstractCompiler$Sandbox$CompilerImpl.process(AbstractCompiler.java:254)
[INFO] at org.eclipse.jdt.internal.compiler.Compiler.compile(Compiler.java:444)
[INFO] at com.google.gwt.dev.jdt.AbstractCompiler$Sandbox$CompilerImpl.compile(AbstractCompiler.java:175)
[INFO] at com.google.gwt.dev.jdt.AbstractCompiler$Sandbox$CompilerImpl.compile(AbstractCompiler.java:288)
[INFO] at com.google.gwt.dev.jdt.AbstractCompiler$Sandbox$CompilerImpl.access$400(AbstractCompiler.java:145)
[INFO] at com.google.gwt.dev.jdt.AbstractCompiler.compile(AbstractCompiler.java:632)
[INFO] at com.google.gwt.dev.jdt.BasicWebModeCompiler.getCompilationUnitDeclarations(BasicWebModeCompiler.java:124)
[INFO] at com.google.gwt.dev.jdt.WebModeCompilerFrontEnd.getCompilationUnitDeclarations(WebModeCompilerFrontEnd.java:54)
[INFO] at com.google.gwt.dev.jjs.JavaToJavaScriptCompiler.precompile(JavaToJavaScriptCompiler.java:517)
[INFO] at com.google.gwt.dev.jjs.JavaScriptCompiler.precompile(JavaScriptCompiler.java:35)
[INFO] at com.google.gwt.dev.Precompile.precompile(Precompile.java:541)
[INFO] at com.google.gwt.dev.Precompile.precompile(Precompile.java:495)
[INFO] at com.google.gwt.dev.Precompile.precompile(Precompile.java:407)
[INFO] at com.google.gwt.dev.Compiler.run(Compiler.java:215)
[INFO] at com.google.gwt.dev.Compiler.run(Compiler.java:187)
[INFO] at com.google.gwt.dev.Compiler$1.run(Compiler.java:159)
[INFO] at com.google.gwt.dev.CompileTaskRunner.doRun(CompileTaskRunner.java:87)
[INFO] at com.google.gwt.dev.CompileTaskRunner.runWithAppropriateLogger(CompileTaskRunner.java:81)
[INFO] at com.google.gwt.dev.Compiler.main(Compiler.java:166)

So as far as I see fit, the constructor signature for the SerializableTypeOracleBuilder has changed in GWT 2.3.0 and Atmosphere 0.8 is already using the new version.

I'll see if I can update to GWT 2.3 for a test.

Cheers,
Mark

----- Ursprüngliche Mail -----
Von: "Jeanfrancois Arcand" <[hidden email]>
An: [hidden email]
Gesendet: Montag, 19. September 2011 17:43:59
Betreff: [atmosphere-users] Re: [] Re: Can't get rid of the BlockIOCometSupport fallback in Tomcat

Salut,

I don't think this is doable...like you observed, Tomcat doesn't like
seeing filter that aren't implementing the CometProcessor stuff and will
never enable the async stuff because of that (ya that sucks I know). The
only solution for you would be to use a Servlet 3.0 container (but I
have read your explanation). But until you go into production you may
"live" with the blocking I/O stuff I would say.

A+

-- Jeanfrancois

On 11-09-19 4:36 AM, Mark Heimann wrote:

> Hi there,
>
> thanks for the quick response. I will try it out with the 0.8-SNAPSHOT version as soon as I can and tell you if it's deployable within Tomcat 7 without the ClassDefNotFound errors.
>
> Just one quick question: From the top of your head, do you know whether there is any way to have Tomcat see the Atmosphere servlet as a CometProcessor when I am configuring it with Guice (i.e. not explicitly putting it into the web.xml file)?
>
> Thanks a lot,
>
> Mark
>
> ----- Ursprüngliche Mail -----
> Von: "Jeanfrancois Arcand"<[hidden email]>
> An: [hidden email]
> Gesendet: Montag, 19. September 2011 01:54:47
> Betreff: [[atmosphere-users]] Re: Can't get rid of the BlockIOCometSupport fallback in Tomcat
>
> Salut,
>
> can you try with atmosphere 0.8? I did fix the Tomcat 7 class namespace
> changes. If that doesn't work can you send me a test case privately? I
> will take a look and see what's happening.
>
> Thanks!
>
> -- Jeanfrancois
>
> On 11-09-16 7:45 AM, Mark Heimann wrote:
>> Little update,
>>
>> I was now able to get TomcatCometSupport used (instead of fallback BlockingIOCometSupport) in Tomcat 6. I rewrote a portion of my application and basically removed my Atmosphere servlet from the servlets that are managed by the Guice servlet extension (the ones that are bound in the Guice module via serve(...).with(ServletClass.class);).
>>
>> Unfortunately I loose the session-scoped objects feature of Guice and I need to manually map my Atmosphere servlet in the web.xml file but so far it's working correctly and I think I can work around this lack of features. My Atmosphere servlet now injects itself by grabbing the Guice injector from the ServletContext (just like in AtmosphereGuiceServlet class) and retrieving whatever it needs from it (in my case one singleton).
>>
>> When I deploy this into Tomcat 7 I get ClassDefNotFoundExceptions for the Comet interface, since the Tomcat team has changed the namespaces for those types as far as I know. What I'd like to know is when the Tomcat7CometSupport implementation will become publicly available? I think it's not in the current stable version (0.7.2) and I would like to rather not depend on snapshots :-). I can't use the Servlet 3.0 API because my web application must be a Servlet 2.5 module (because of GWT).
>>
>> Big question at the end would be: Is there any way to deploy a CometProcessor implementor (such as the AtmosphereServlet) inside Tomcat that's managed by Guice (with guice-servlet extension)? Because if not I kind of think that Atmosphere's Guice integration is obsolete, or am I not seeing things clearly there?
>>
>> Cheers,
>> Mark
>>
>> ----- Ursprüngliche Mail -----
>> Von: [hidden email]
>> An: [hidden email]
>> Gesendet: Freitag, 16. September 2011 12:49:23
>> Betreff: Can't get rid of the BlockIOCometSupport fallback in Tomcat
>>
>> Hi everyone,
>>
>> I know this issue has been raised a couple times already, so sorry for
>> reposting it. I can't figure out how to resolve this even after reading
>> through pretty much anything I've found on the issue.
>>
>> The problem is the following warning in my server's log file:
>>
>> 2011-09-16 12:00:36,623 [http-8080-exec-1] WARN
>> org.atmosphere.cpr.AtmosphereServlet - failed using comet support:
>> org.atmosphere.container.TomcatCometSupport, error: Tomcat failed to
>> detect this is a Comet application because context.xml is missing or
>> the Http11NioProtocol Connector is not enabled.
>> If that's not the case, you can also remove META-INF/context.xml and
>> WEB-INF/lib/atmosphere-compat-tomcat.jar
>> 2011-09-16 12:00:36,625 [http-8080-exec-1] WARN
>> org.atmosphere.cpr.AtmosphereServlet - Using BlockingIOCometSupport.
>>
>> I am using version 0.7.1 of Atmosphere in combination with the Guice
>> integration module (atmosphere-guice) as well as the Google Web Toolkit
>> (GWT) integration (atmosphere-gwt-common, atmosphere-gwt-client,
>> atmosphere-gwt-server, atmosphere-gwt-poll). There are also the
>> atmosphere-runtime (obviously), the atmosphere-jersey and the
>> atmosphere-annotations JARs on my classpath but they shouldn't be in
>> use (except by Atmosphere internally).
>>
>> What have I done so far:
>>
>> 0) I have tried getting it to work on Tomcat 7 (v7.0.21) and Tomcat 6
>> (v6.0.33); on Tomcat 7 I also can't get it to use Servlet 3.0 (maybe
>> because GWT requires me to specify the web module to be a version 2.5
>> module)
>> 1) I have enabled the Http11NioProtocol Connnector in my Tomcat
>> server.xml configuration.
>> 2) I have removed the "atmosphere-compat-tomcat-0.7.1.jar" from
>> WEB-INF/lib since it contains fake classes only. (this only works for
>> Tomcat 6 since Tomcat 7 requires the fake classes from the JAR because
>> it appears that the namespaces for Tomcat's Comet types have changed)
>> 3) I have tried removing the META-INF/context.xml to no avail.
>> 4) I have tried adding<Loader delegate="true"/>   to
>> META-INF/context.xml
>>
>> I think my issue has to do with the fact that I am using the Guice
>> integration (or the GWT integration).
>>
>> The only thread I've found/read that deals with resolving something
>> similar is this one:
>> http://atmosphere-users-mailling-list.2493822.n2.nabble.com/New-Guice-i
>> ntegration-always-uses-blocking-IO-on-Tomcat-td4469089.html
>>
>> I've noticed that the fix proposed there is included in the
>> AtmosphereGuiceServlet class as well as the
>> GuiceManagedAtmosphereServlet class. The code in the method
>> detectSupportedFramework() is however never called in my case since I
>> supply an atmosphere.xml that defines one dummy handler that I
>> programmatically remove before programmatically adding my own handler
>> (I do this adding of the atmosphere handler programmatically because
>> the handler itself is constructed by Guice since it depends on some
>> other application classes that are injected to its constructor; if I
>> don't do it this way, it blows up at creation time since the handler
>> does not define a default constructor). Could this be somehow related
>> to my problem? (Sorry, I've been getting slightly confused over the
>> past 3 hours)
>>
>> Does anyone have any additional hints what I could try in order to
>> activate the non-blocking support for Tomcat?
>>
>> Would greatly appreciate any help, thanks a lot!
>>
>> - Mark
Reply | Threaded
Open this post in threaded view
|

[atmosphere-users] Re: [] Re: Can't get rid of the BlockIOCometSupport fallback in Tomcat

Jeanfrancois Arcand-4
Salut,

OK keep us posted. BTW This list will soon be closed, CC the new one.

-- Jeanfrancois

On 11-09-20 12:31 AM, Mark Heimann wrote:

> Hi,
>
> just checked with 0.8-SNAPSHOT from the http://oss.sonatype.org/content/repositories/snapshots/ repository. I can't get the GWT compiler step working, looks like the serialization code is incompatible with my GWT version (2.2.0).
>
> I get the following stack trace during the mentioned compilation step:
>
> [INFO] Compiling module XXXXXXX
> [INFO]    [ERROR] Errors in 'file:/XXXXXX'
> [INFO]       [ERROR]  Internal compiler error
> [INFO] java.lang.NoSuchMethodError: com.google.gwt.user.rebind.rpc.SerializableTypeOracleBuilder.<init>(Lcom/google/gwt/core/ext/TreeLogger;Lcom/google/gwt/core/ext/PropertyOracle;Lcom/google/gwt/core/ext/GeneratorContextExt;)V
> [INFO] at org.atmosphere.gwt.rebind.SerializerGenerator.generateIncrementally(SerializerGenerator.java:86)
> [INFO] at com.google.gwt.dev.javac.StandardGeneratorContext.runGeneratorIncrementally(StandardGeneratorContext.java:662)
> [INFO] at com.google.gwt.dev.cfg.RuleGenerateWith.realize(RuleGenerateWith.java:41)
> [INFO] at com.google.gwt.dev.shell.StandardRebindOracle$Rebinder.rebind(StandardRebindOracle.java:74)
> [INFO] at com.google.gwt.dev.shell.StandardRebindOracle.rebind(StandardRebindOracle.java:259)
> [INFO] at com.google.gwt.dev.shell.StandardRebindOracle.rebind(StandardRebindOracle.java:248)
> [INFO] at com.google.gwt.dev.DistillerRebindPermutationOracle.getAllPossibleRebindAnswers(DistillerRebindPermutationOracle.java:91)
> [INFO] at com.google.gwt.dev.jdt.WebModeCompilerFrontEnd.doFindAdditionalTypesUsingRebinds(WebModeCompilerFrontEnd.java:106)
> [INFO] at com.google.gwt.dev.jdt.AbstractCompiler$Sandbox$CompilerImpl.process(AbstractCompiler.java:254)
> [INFO] at org.eclipse.jdt.internal.compiler.Compiler.compile(Compiler.java:444)
> [INFO] at com.google.gwt.dev.jdt.AbstractCompiler$Sandbox$CompilerImpl.compile(AbstractCompiler.java:175)
> [INFO] at com.google.gwt.dev.jdt.AbstractCompiler$Sandbox$CompilerImpl.compile(AbstractCompiler.java:288)
> [INFO] at com.google.gwt.dev.jdt.AbstractCompiler$Sandbox$CompilerImpl.access$400(AbstractCompiler.java:145)
> [INFO] at com.google.gwt.dev.jdt.AbstractCompiler.compile(AbstractCompiler.java:632)
> [INFO] at com.google.gwt.dev.jdt.BasicWebModeCompiler.getCompilationUnitDeclarations(BasicWebModeCompiler.java:124)
> [INFO] at com.google.gwt.dev.jdt.WebModeCompilerFrontEnd.getCompilationUnitDeclarations(WebModeCompilerFrontEnd.java:54)
> [INFO] at com.google.gwt.dev.jjs.JavaToJavaScriptCompiler.precompile(JavaToJavaScriptCompiler.java:517)
> [INFO] at com.google.gwt.dev.jjs.JavaScriptCompiler.precompile(JavaScriptCompiler.java:35)
> [INFO] at com.google.gwt.dev.Precompile.precompile(Precompile.java:541)
> [INFO] at com.google.gwt.dev.Precompile.precompile(Precompile.java:495)
> [INFO] at com.google.gwt.dev.Precompile.precompile(Precompile.java:407)
> [INFO] at com.google.gwt.dev.Compiler.run(Compiler.java:215)
> [INFO] at com.google.gwt.dev.Compiler.run(Compiler.java:187)
> [INFO] at com.google.gwt.dev.Compiler$1.run(Compiler.java:159)
> [INFO] at com.google.gwt.dev.CompileTaskRunner.doRun(CompileTaskRunner.java:87)
> [INFO] at com.google.gwt.dev.CompileTaskRunner.runWithAppropriateLogger(CompileTaskRunner.java:81)
> [INFO] at com.google.gwt.dev.Compiler.main(Compiler.java:166)
>
> So as far as I see fit, the constructor signature for the SerializableTypeOracleBuilder has changed in GWT 2.3.0 and Atmosphere 0.8 is already using the new version.
>
> I'll see if I can update to GWT 2.3 for a test.
>
> Cheers,
> Mark
>
> ----- Ursprüngliche Mail -----
> Von: "Jeanfrancois Arcand"<[hidden email]>
> An: [hidden email]
> Gesendet: Montag, 19. September 2011 17:43:59
> Betreff: [atmosphere-users] Re: [] Re: Can't get rid of the BlockIOCometSupport fallback in Tomcat
>
> Salut,
>
> I don't think this is doable...like you observed, Tomcat doesn't like
> seeing filter that aren't implementing the CometProcessor stuff and will
> never enable the async stuff because of that (ya that sucks I know). The
> only solution for you would be to use a Servlet 3.0 container (but I
> have read your explanation). But until you go into production you may
> "live" with the blocking I/O stuff I would say.
>
> A+
>
> -- Jeanfrancois
>
> On 11-09-19 4:36 AM, Mark Heimann wrote:
>> Hi there,
>>
>> thanks for the quick response. I will try it out with the 0.8-SNAPSHOT version as soon as I can and tell you if it's deployable within Tomcat 7 without the ClassDefNotFound errors.
>>
>> Just one quick question: From the top of your head, do you know whether there is any way to have Tomcat see the Atmosphere servlet as a CometProcessor when I am configuring it with Guice (i.e. not explicitly putting it into the web.xml file)?
>>
>> Thanks a lot,
>>
>> Mark
>>
>> ----- Ursprüngliche Mail -----
>> Von: "Jeanfrancois Arcand"<[hidden email]>
>> An: [hidden email]
>> Gesendet: Montag, 19. September 2011 01:54:47
>> Betreff: [[atmosphere-users]] Re: Can't get rid of the BlockIOCometSupport fallback in Tomcat
>>
>> Salut,
>>
>> can you try with atmosphere 0.8? I did fix the Tomcat 7 class namespace
>> changes. If that doesn't work can you send me a test case privately? I
>> will take a look and see what's happening.
>>
>> Thanks!
>>
>> -- Jeanfrancois
>>
>> On 11-09-16 7:45 AM, Mark Heimann wrote:
>>> Little update,
>>>
>>> I was now able to get TomcatCometSupport used (instead of fallback BlockingIOCometSupport) in Tomcat 6. I rewrote a portion of my application and basically removed my Atmosphere servlet from the servlets that are managed by the Guice servlet extension (the ones that are bound in the Guice module via serve(...).with(ServletClass.class);).
>>>
>>> Unfortunately I loose the session-scoped objects feature of Guice and I need to manually map my Atmosphere servlet in the web.xml file but so far it's working correctly and I think I can work around this lack of features. My Atmosphere servlet now injects itself by grabbing the Guice injector from the ServletContext (just like in AtmosphereGuiceServlet class) and retrieving whatever it needs from it (in my case one singleton).
>>>
>>> When I deploy this into Tomcat 7 I get ClassDefNotFoundExceptions for the Comet interface, since the Tomcat team has changed the namespaces for those types as far as I know. What I'd like to know is when the Tomcat7CometSupport implementation will become publicly available? I think it's not in the current stable version (0.7.2) and I would like to rather not depend on snapshots :-). I can't use the Servlet 3.0 API because my web application must be a Servlet 2.5 module (because of GWT).
>>>
>>> Big question at the end would be: Is there any way to deploy a CometProcessor implementor (such as the AtmosphereServlet) inside Tomcat that's managed by Guice (with guice-servlet extension)? Because if not I kind of think that Atmosphere's Guice integration is obsolete, or am I not seeing things clearly there?
>>>
>>> Cheers,
>>> Mark
>>>
>>> ----- Ursprüngliche Mail -----
>>> Von: [hidden email]
>>> An: [hidden email]
>>> Gesendet: Freitag, 16. September 2011 12:49:23
>>> Betreff: Can't get rid of the BlockIOCometSupport fallback in Tomcat
>>>
>>> Hi everyone,
>>>
>>> I know this issue has been raised a couple times already, so sorry for
>>> reposting it. I can't figure out how to resolve this even after reading
>>> through pretty much anything I've found on the issue.
>>>
>>> The problem is the following warning in my server's log file:
>>>
>>> 2011-09-16 12:00:36,623 [http-8080-exec-1] WARN
>>> org.atmosphere.cpr.AtmosphereServlet - failed using comet support:
>>> org.atmosphere.container.TomcatCometSupport, error: Tomcat failed to
>>> detect this is a Comet application because context.xml is missing or
>>> the Http11NioProtocol Connector is not enabled.
>>> If that's not the case, you can also remove META-INF/context.xml and
>>> WEB-INF/lib/atmosphere-compat-tomcat.jar
>>> 2011-09-16 12:00:36,625 [http-8080-exec-1] WARN
>>> org.atmosphere.cpr.AtmosphereServlet - Using BlockingIOCometSupport.
>>>
>>> I am using version 0.7.1 of Atmosphere in combination with the Guice
>>> integration module (atmosphere-guice) as well as the Google Web Toolkit
>>> (GWT) integration (atmosphere-gwt-common, atmosphere-gwt-client,
>>> atmosphere-gwt-server, atmosphere-gwt-poll). There are also the
>>> atmosphere-runtime (obviously), the atmosphere-jersey and the
>>> atmosphere-annotations JARs on my classpath but they shouldn't be in
>>> use (except by Atmosphere internally).
>>>
>>> What have I done so far:
>>>
>>> 0) I have tried getting it to work on Tomcat 7 (v7.0.21) and Tomcat 6
>>> (v6.0.33); on Tomcat 7 I also can't get it to use Servlet 3.0 (maybe
>>> because GWT requires me to specify the web module to be a version 2.5
>>> module)
>>> 1) I have enabled the Http11NioProtocol Connnector in my Tomcat
>>> server.xml configuration.
>>> 2) I have removed the "atmosphere-compat-tomcat-0.7.1.jar" from
>>> WEB-INF/lib since it contains fake classes only. (this only works for
>>> Tomcat 6 since Tomcat 7 requires the fake classes from the JAR because
>>> it appears that the namespaces for Tomcat's Comet types have changed)
>>> 3) I have tried removing the META-INF/context.xml to no avail.
>>> 4) I have tried adding<Loader delegate="true"/>    to
>>> META-INF/context.xml
>>>
>>> I think my issue has to do with the fact that I am using the Guice
>>> integration (or the GWT integration).
>>>
>>> The only thread I've found/read that deals with resolving something
>>> similar is this one:
>>> http://atmosphere-users-mailling-list.2493822.n2.nabble.com/New-Guice-i
>>> ntegration-always-uses-blocking-IO-on-Tomcat-td4469089.html
>>>
>>> I've noticed that the fix proposed there is included in the
>>> AtmosphereGuiceServlet class as well as the
>>> GuiceManagedAtmosphereServlet class. The code in the method
>>> detectSupportedFramework() is however never called in my case since I
>>> supply an atmosphere.xml that defines one dummy handler that I
>>> programmatically remove before programmatically adding my own handler
>>> (I do this adding of the atmosphere handler programmatically because
>>> the handler itself is constructed by Guice since it depends on some
>>> other application classes that are injected to its constructor; if I
>>> don't do it this way, it blows up at creation time since the handler
>>> does not define a default constructor). Could this be somehow related
>>> to my problem? (Sorry, I've been getting slightly confused over the
>>> past 3 hours)
>>>
>>> Does anyone have any additional hints what I could try in order to
>>> activate the non-blocking support for Tomcat?
>>>
>>> Would greatly appreciate any help, thanks a lot!
>>>
>>> - Mark
Reply | Threaded
Open this post in threaded view
|

[atmosphere-users] Re: [] Re: Can't get rid of the BlockIOCometSupport fallback in Tomcat

java.net
In reply to this post by Mark H
GWT version for 0.8-SNAPSHOT is 2.3.0

On 20-9-2011 9:31, Mark Heimann wrote:

> Hi,
>
> just checked with 0.8-SNAPSHOT from the http://oss.sonatype.org/content/repositories/snapshots/ repository. I can't get the GWT compiler step working, looks like the serialization code is incompatible with my GWT version (2.2.0).
>
> I get the following stack trace during the mentioned compilation step:
>
> [INFO] Compiling module XXXXXXX
> [INFO]    [ERROR] Errors in 'file:/XXXXXX'
> [INFO]       [ERROR]  Internal compiler error
> [INFO] java.lang.NoSuchMethodError: com.google.gwt.user.rebind.rpc.SerializableTypeOracleBuilder.<init>(Lcom/google/gwt/core/ext/TreeLogger;Lcom/google/gwt/core/ext/PropertyOracle;Lcom/google/gwt/core/ext/GeneratorContextExt;)V
> [INFO] at org.atmosphere.gwt.rebind.SerializerGenerator.generateIncrementally(SerializerGenerator.java:86)
> [INFO] at com.google.gwt.dev.javac.StandardGeneratorContext.runGeneratorIncrementally(StandardGeneratorContext.java:662)
> [INFO] at com.google.gwt.dev.cfg.RuleGenerateWith.realize(RuleGenerateWith.java:41)
> [INFO] at com.google.gwt.dev.shell.StandardRebindOracle$Rebinder.rebind(StandardRebindOracle.java:74)
> [INFO] at com.google.gwt.dev.shell.StandardRebindOracle.rebind(StandardRebindOracle.java:259)
> [INFO] at com.google.gwt.dev.shell.StandardRebindOracle.rebind(StandardRebindOracle.java:248)
> [INFO] at com.google.gwt.dev.DistillerRebindPermutationOracle.getAllPossibleRebindAnswers(DistillerRebindPermutationOracle.java:91)
> [INFO] at com.google.gwt.dev.jdt.WebModeCompilerFrontEnd.doFindAdditionalTypesUsingRebinds(WebModeCompilerFrontEnd.java:106)
> [INFO] at com.google.gwt.dev.jdt.AbstractCompiler$Sandbox$CompilerImpl.process(AbstractCompiler.java:254)
> [INFO] at org.eclipse.jdt.internal.compiler.Compiler.compile(Compiler.java:444)
> [INFO] at com.google.gwt.dev.jdt.AbstractCompiler$Sandbox$CompilerImpl.compile(AbstractCompiler.java:175)
> [INFO] at com.google.gwt.dev.jdt.AbstractCompiler$Sandbox$CompilerImpl.compile(AbstractCompiler.java:288)
> [INFO] at com.google.gwt.dev.jdt.AbstractCompiler$Sandbox$CompilerImpl.access$400(AbstractCompiler.java:145)
> [INFO] at com.google.gwt.dev.jdt.AbstractCompiler.compile(AbstractCompiler.java:632)
> [INFO] at com.google.gwt.dev.jdt.BasicWebModeCompiler.getCompilationUnitDeclarations(BasicWebModeCompiler.java:124)
> [INFO] at com.google.gwt.dev.jdt.WebModeCompilerFrontEnd.getCompilationUnitDeclarations(WebModeCompilerFrontEnd.java:54)
> [INFO] at com.google.gwt.dev.jjs.JavaToJavaScriptCompiler.precompile(JavaToJavaScriptCompiler.java:517)
> [INFO] at com.google.gwt.dev.jjs.JavaScriptCompiler.precompile(JavaScriptCompiler.java:35)
> [INFO] at com.google.gwt.dev.Precompile.precompile(Precompile.java:541)
> [INFO] at com.google.gwt.dev.Precompile.precompile(Precompile.java:495)
> [INFO] at com.google.gwt.dev.Precompile.precompile(Precompile.java:407)
> [INFO] at com.google.gwt.dev.Compiler.run(Compiler.java:215)
> [INFO] at com.google.gwt.dev.Compiler.run(Compiler.java:187)
> [INFO] at com.google.gwt.dev.Compiler$1.run(Compiler.java:159)
> [INFO] at com.google.gwt.dev.CompileTaskRunner.doRun(CompileTaskRunner.java:87)
> [INFO] at com.google.gwt.dev.CompileTaskRunner.runWithAppropriateLogger(CompileTaskRunner.java:81)
> [INFO] at com.google.gwt.dev.Compiler.main(Compiler.java:166)
>
> So as far as I see fit, the constructor signature for the SerializableTypeOracleBuilder has changed in GWT 2.3.0 and Atmosphere 0.8 is already using the new version.
>
> I'll see if I can update to GWT 2.3 for a test.
>
> Cheers,
> Mark
>
> ----- Ursprüngliche Mail -----
> Von: "Jeanfrancois Arcand"<[hidden email]>
> An: [hidden email]
> Gesendet: Montag, 19. September 2011 17:43:59
> Betreff: [atmosphere-users] Re: [] Re: Can't get rid of the BlockIOCometSupport fallback in Tomcat
>
> Salut,
>
> I don't think this is doable...like you observed, Tomcat doesn't like
> seeing filter that aren't implementing the CometProcessor stuff and will
> never enable the async stuff because of that (ya that sucks I know). The
> only solution for you would be to use a Servlet 3.0 container (but I
> have read your explanation). But until you go into production you may
> "live" with the blocking I/O stuff I would say.
>
> A+
>
> -- Jeanfrancois
>
> On 11-09-19 4:36 AM, Mark Heimann wrote:
>> Hi there,
>>
>> thanks for the quick response. I will try it out with the 0.8-SNAPSHOT version as soon as I can and tell you if it's deployable within Tomcat 7 without the ClassDefNotFound errors.
>>
>> Just one quick question: From the top of your head, do you know whether there is any way to have Tomcat see the Atmosphere servlet as a CometProcessor when I am configuring it with Guice (i.e. not explicitly putting it into the web.xml file)?
>>
>> Thanks a lot,
>>
>> Mark
>>
>> ----- Ursprüngliche Mail -----
>> Von: "Jeanfrancois Arcand"<[hidden email]>
>> An: [hidden email]
>> Gesendet: Montag, 19. September 2011 01:54:47
>> Betreff: [[atmosphere-users]] Re: Can't get rid of the BlockIOCometSupport fallback in Tomcat
>>
>> Salut,
>>
>> can you try with atmosphere 0.8? I did fix the Tomcat 7 class namespace
>> changes. If that doesn't work can you send me a test case privately? I
>> will take a look and see what's happening.
>>
>> Thanks!
>>
>> -- Jeanfrancois
>>
>> On 11-09-16 7:45 AM, Mark Heimann wrote:
>>> Little update,
>>>
>>> I was now able to get TomcatCometSupport used (instead of fallback BlockingIOCometSupport) in Tomcat 6. I rewrote a portion of my application and basically removed my Atmosphere servlet from the servlets that are managed by the Guice servlet extension (the ones that are bound in the Guice module via serve(...).with(ServletClass.class);).
>>>
>>> Unfortunately I loose the session-scoped objects feature of Guice and I need to manually map my Atmosphere servlet in the web.xml file but so far it's working correctly and I think I can work around this lack of features. My Atmosphere servlet now injects itself by grabbing the Guice injector from the ServletContext (just like in AtmosphereGuiceServlet class) and retrieving whatever it needs from it (in my case one singleton).
>>>
>>> When I deploy this into Tomcat 7 I get ClassDefNotFoundExceptions for the Comet interface, since the Tomcat team has changed the namespaces for those types as far as I know. What I'd like to know is when the Tomcat7CometSupport implementation will become publicly available? I think it's not in the current stable version (0.7.2) and I would like to rather not depend on snapshots :-). I can't use the Servlet 3.0 API because my web application must be a Servlet 2.5 module (because of GWT).
>>>
>>> Big question at the end would be: Is there any way to deploy a CometProcessor implementor (such as the AtmosphereServlet) inside Tomcat that's managed by Guice (with guice-servlet extension)? Because if not I kind of think that Atmosphere's Guice integration is obsolete, or am I not seeing things clearly there?
>>>
>>> Cheers,
>>> Mark
>>>
>>> ----- Ursprüngliche Mail -----
>>> Von: [hidden email]
>>> An: [hidden email]
>>> Gesendet: Freitag, 16. September 2011 12:49:23
>>> Betreff: Can't get rid of the BlockIOCometSupport fallback in Tomcat
>>>
>>> Hi everyone,
>>>
>>> I know this issue has been raised a couple times already, so sorry for
>>> reposting it. I can't figure out how to resolve this even after reading
>>> through pretty much anything I've found on the issue.
>>>
>>> The problem is the following warning in my server's log file:
>>>
>>> 2011-09-16 12:00:36,623 [http-8080-exec-1] WARN
>>> org.atmosphere.cpr.AtmosphereServlet - failed using comet support:
>>> org.atmosphere.container.TomcatCometSupport, error: Tomcat failed to
>>> detect this is a Comet application because context.xml is missing or
>>> the Http11NioProtocol Connector is not enabled.
>>> If that's not the case, you can also remove META-INF/context.xml and
>>> WEB-INF/lib/atmosphere-compat-tomcat.jar
>>> 2011-09-16 12:00:36,625 [http-8080-exec-1] WARN
>>> org.atmosphere.cpr.AtmosphereServlet - Using BlockingIOCometSupport.
>>>
>>> I am using version 0.7.1 of Atmosphere in combination with the Guice
>>> integration module (atmosphere-guice) as well as the Google Web Toolkit
>>> (GWT) integration (atmosphere-gwt-common, atmosphere-gwt-client,
>>> atmosphere-gwt-server, atmosphere-gwt-poll). There are also the
>>> atmosphere-runtime (obviously), the atmosphere-jersey and the
>>> atmosphere-annotations JARs on my classpath but they shouldn't be in
>>> use (except by Atmosphere internally).
>>>
>>> What have I done so far:
>>>
>>> 0) I have tried getting it to work on Tomcat 7 (v7.0.21) and Tomcat 6
>>> (v6.0.33); on Tomcat 7 I also can't get it to use Servlet 3.0 (maybe
>>> because GWT requires me to specify the web module to be a version 2.5
>>> module)
>>> 1) I have enabled the Http11NioProtocol Connnector in my Tomcat
>>> server.xml configuration.
>>> 2) I have removed the "atmosphere-compat-tomcat-0.7.1.jar" from
>>> WEB-INF/lib since it contains fake classes only. (this only works for
>>> Tomcat 6 since Tomcat 7 requires the fake classes from the JAR because
>>> it appears that the namespaces for Tomcat's Comet types have changed)
>>> 3) I have tried removing the META-INF/context.xml to no avail.
>>> 4) I have tried adding<Loader delegate="true"/>    to
>>> META-INF/context.xml
>>>
>>> I think my issue has to do with the fact that I am using the Guice
>>> integration (or the GWT integration).
>>>
>>> The only thread I've found/read that deals with resolving something
>>> similar is this one:
>>> http://atmosphere-users-mailling-list.2493822.n2.nabble.com/New-Guice-i
>>> ntegration-always-uses-blocking-IO-on-Tomcat-td4469089.html
>>>
>>> I've noticed that the fix proposed there is included in the
>>> AtmosphereGuiceServlet class as well as the
>>> GuiceManagedAtmosphereServlet class. The code in the method
>>> detectSupportedFramework() is however never called in my case since I
>>> supply an atmosphere.xml that defines one dummy handler that I
>>> programmatically remove before programmatically adding my own handler
>>> (I do this adding of the atmosphere handler programmatically because
>>> the handler itself is constructed by Guice since it depends on some
>>> other application classes that are injected to its constructor; if I
>>> don't do it this way, it blows up at creation time since the handler
>>> does not define a default constructor). Could this be somehow related
>>> to my problem? (Sorry, I've been getting slightly confused over the
>>> past 3 hours)
>>>
>>> Does anyone have any additional hints what I could try in order to
>>> activate the non-blocking support for Tomcat?
>>>
>>> Would greatly appreciate any help, thanks a lot!
>>>
>>> - Mark
Reply | Threaded
Open this post in threaded view
|

[atmosphere-users] Re: [] Re: Can't get rid of the BlockIOCometSupport fallback in Tomcat

Mark H
In reply to this post by Jeanfrancois Arcand-4
Hi again,

after some hassles we've managed to update to GWT 2.4.0 for our project (took longer because the interaction of all the Eclipse plugins is somewhat confusing). Anyways, I can compile the project now with 0.8-SNAPSHOT version of Atmosphere and I can get it to work in GWT's development mode (using Jetty, don't know which version) and Tomcat 7 (with Tomcat7CometSupport) under some conditions:

1. We need to specify the "org.atmosphere.useNative" (value = true) init param for my servlet (if I don't do that, it tries to use Servlet 3 and fails miserably in GWT DevMode's embedded Jetty; I haven't tried skipped useNative in Tomcat 7 but I expect it to fail as well due to our web application being defined as a Servlet 2.5 app in the web.xml)
2. We need to specify <Loader delegate="true" /> in my META-INF/context.xml file (to avoid ClassDefNotFound)
3. We needed to change some of our application code in relation to Atmosphere because of API changes in Atmosphere 0.8 (no big deals though; getBroadcaster(...) changed it's behavior and gave us some NullReferenceExceptions).

It's also worth mentioning that (I think) it's no longer necessary to remove the atmosphere-compat-tomcat-XXX.jar when the loader delegation is activated (point 2 above). If you now want to deploy this in Tomcat 6 you also need to supply the "org.atmosphere.cpr.cometSupport" init parameter because Tomcat7CometSupport seems to be the default and it throws some errors if you don't do that, snippet from the web.xml looks as follows:

<init-param>
    <param-name>org.atmosphere.cpr.cometSupport</param-name>
    <param-value>org.atmosphere.container.TomcatCometSupport</param-value>
</init-param>

Please correct me if I'm stating wrong things :-)

Cheers,
Mark

----- Ursprüngliche Mail -----
Von: "Jeanfrancois Arcand" <[hidden email]>
An: [hidden email], [hidden email]
Gesendet: Dienstag, 20. September 2011 18:06:25
Betreff: [atmosphere-users] Re: [] Re: Can't get rid of the BlockIOCometSupport fallback in Tomcat

Salut,

OK keep us posted. BTW This list will soon be closed, CC the new one.

-- Jeanfrancois

On 11-09-20 12:31 AM, Mark Heimann wrote:

> Hi,
>
> just checked with 0.8-SNAPSHOT from the http://oss.sonatype.org/content/repositories/snapshots/ repository. I can't get the GWT compiler step working, looks like the serialization code is incompatible with my GWT version (2.2.0).
>
> I get the following stack trace during the mentioned compilation step:
>
> [INFO] Compiling module XXXXXXX
> [INFO]    [ERROR] Errors in 'file:/XXXXXX'
> [INFO]       [ERROR]  Internal compiler error
> [INFO] java.lang.NoSuchMethodError: com.google.gwt.user.rebind.rpc.SerializableTypeOracleBuilder.<init>(Lcom/google/gwt/core/ext/TreeLogger;Lcom/google/gwt/core/ext/PropertyOracle;Lcom/google/gwt/core/ext/GeneratorContextExt;)V
> [INFO] at org.atmosphere.gwt.rebind.SerializerGenerator.generateIncrementally(SerializerGenerator.java:86)
> [INFO] at com.google.gwt.dev.javac.StandardGeneratorContext.runGeneratorIncrementally(StandardGeneratorContext.java:662)
> [INFO] at com.google.gwt.dev.cfg.RuleGenerateWith.realize(RuleGenerateWith.java:41)
> [INFO] at com.google.gwt.dev.shell.StandardRebindOracle$Rebinder.rebind(StandardRebindOracle.java:74)
> [INFO] at com.google.gwt.dev.shell.StandardRebindOracle.rebind(StandardRebindOracle.java:259)
> [INFO] at com.google.gwt.dev.shell.StandardRebindOracle.rebind(StandardRebindOracle.java:248)
> [INFO] at com.google.gwt.dev.DistillerRebindPermutationOracle.getAllPossibleRebindAnswers(DistillerRebindPermutationOracle.java:91)
> [INFO] at com.google.gwt.dev.jdt.WebModeCompilerFrontEnd.doFindAdditionalTypesUsingRebinds(WebModeCompilerFrontEnd.java:106)
> [INFO] at com.google.gwt.dev.jdt.AbstractCompiler$Sandbox$CompilerImpl.process(AbstractCompiler.java:254)
> [INFO] at org.eclipse.jdt.internal.compiler.Compiler.compile(Compiler.java:444)
> [INFO] at com.google.gwt.dev.jdt.AbstractCompiler$Sandbox$CompilerImpl.compile(AbstractCompiler.java:175)
> [INFO] at com.google.gwt.dev.jdt.AbstractCompiler$Sandbox$CompilerImpl.compile(AbstractCompiler.java:288)
> [INFO] at com.google.gwt.dev.jdt.AbstractCompiler$Sandbox$CompilerImpl.access$400(AbstractCompiler.java:145)
> [INFO] at com.google.gwt.dev.jdt.AbstractCompiler.compile(AbstractCompiler.java:632)
> [INFO] at com.google.gwt.dev.jdt.BasicWebModeCompiler.getCompilationUnitDeclarations(BasicWebModeCompiler.java:124)
> [INFO] at com.google.gwt.dev.jdt.WebModeCompilerFrontEnd.getCompilationUnitDeclarations(WebModeCompilerFrontEnd.java:54)
> [INFO] at com.google.gwt.dev.jjs.JavaToJavaScriptCompiler.precompile(JavaToJavaScriptCompiler.java:517)
> [INFO] at com.google.gwt.dev.jjs.JavaScriptCompiler.precompile(JavaScriptCompiler.java:35)
> [INFO] at com.google.gwt.dev.Precompile.precompile(Precompile.java:541)
> [INFO] at com.google.gwt.dev.Precompile.precompile(Precompile.java:495)
> [INFO] at com.google.gwt.dev.Precompile.precompile(Precompile.java:407)
> [INFO] at com.google.gwt.dev.Compiler.run(Compiler.java:215)
> [INFO] at com.google.gwt.dev.Compiler.run(Compiler.java:187)
> [INFO] at com.google.gwt.dev.Compiler$1.run(Compiler.java:159)
> [INFO] at com.google.gwt.dev.CompileTaskRunner.doRun(CompileTaskRunner.java:87)
> [INFO] at com.google.gwt.dev.CompileTaskRunner.runWithAppropriateLogger(CompileTaskRunner.java:81)
> [INFO] at com.google.gwt.dev.Compiler.main(Compiler.java:166)
>
> So as far as I see fit, the constructor signature for the SerializableTypeOracleBuilder has changed in GWT 2.3.0 and Atmosphere 0.8 is already using the new version.
>
> I'll see if I can update to GWT 2.3 for a test.
>
> Cheers,
> Mark
>
> ----- Ursprüngliche Mail -----
> Von: "Jeanfrancois Arcand"<[hidden email]>
> An: [hidden email]
> Gesendet: Montag, 19. September 2011 17:43:59
> Betreff: [atmosphere-users] Re: [] Re: Can't get rid of the BlockIOCometSupport fallback in Tomcat
>
> Salut,
>
> I don't think this is doable...like you observed, Tomcat doesn't like
> seeing filter that aren't implementing the CometProcessor stuff and will
> never enable the async stuff because of that (ya that sucks I know). The
> only solution for you would be to use a Servlet 3.0 container (but I
> have read your explanation). But until you go into production you may
> "live" with the blocking I/O stuff I would say.
>
> A+
>
> -- Jeanfrancois
>
> On 11-09-19 4:36 AM, Mark Heimann wrote:
>> Hi there,
>>
>> thanks for the quick response. I will try it out with the 0.8-SNAPSHOT version as soon as I can and tell you if it's deployable within Tomcat 7 without the ClassDefNotFound errors.
>>
>> Just one quick question: From the top of your head, do you know whether there is any way to have Tomcat see the Atmosphere servlet as a CometProcessor when I am configuring it with Guice (i.e. not explicitly putting it into the web.xml file)?
>>
>> Thanks a lot,
>>
>> Mark
>>
>> ----- Ursprüngliche Mail -----
>> Von: "Jeanfrancois Arcand"<[hidden email]>
>> An: [hidden email]
>> Gesendet: Montag, 19. September 2011 01:54:47
>> Betreff: [[atmosphere-users]] Re: Can't get rid of the BlockIOCometSupport fallback in Tomcat
>>
>> Salut,
>>
>> can you try with atmosphere 0.8? I did fix the Tomcat 7 class namespace
>> changes. If that doesn't work can you send me a test case privately? I
>> will take a look and see what's happening.
>>
>> Thanks!
>>
>> -- Jeanfrancois
>>
>> On 11-09-16 7:45 AM, Mark Heimann wrote:
>>> Little update,
>>>
>>> I was now able to get TomcatCometSupport used (instead of fallback BlockingIOCometSupport) in Tomcat 6. I rewrote a portion of my application and basically removed my Atmosphere servlet from the servlets that are managed by the Guice servlet extension (the ones that are bound in the Guice module via serve(...).with(ServletClass.class);).
>>>
>>> Unfortunately I loose the session-scoped objects feature of Guice and I need to manually map my Atmosphere servlet in the web.xml file but so far it's working correctly and I think I can work around this lack of features. My Atmosphere servlet now injects itself by grabbing the Guice injector from the ServletContext (just like in AtmosphereGuiceServlet class) and retrieving whatever it needs from it (in my case one singleton).
>>>
>>> When I deploy this into Tomcat 7 I get ClassDefNotFoundExceptions for the Comet interface, since the Tomcat team has changed the namespaces for those types as far as I know. What I'd like to know is when the Tomcat7CometSupport implementation will become publicly available? I think it's not in the current stable version (0.7.2) and I would like to rather not depend on snapshots :-). I can't use the Servlet 3.0 API because my web application must be a Servlet 2.5 module (because of GWT).
>>>
>>> Big question at the end would be: Is there any way to deploy a CometProcessor implementor (such as the AtmosphereServlet) inside Tomcat that's managed by Guice (with guice-servlet extension)? Because if not I kind of think that Atmosphere's Guice integration is obsolete, or am I not seeing things clearly there?
>>>
>>> Cheers,
>>> Mark
>>>
>>> ----- Ursprüngliche Mail -----
>>> Von: [hidden email]
>>> An: [hidden email]
>>> Gesendet: Freitag, 16. September 2011 12:49:23
>>> Betreff: Can't get rid of the BlockIOCometSupport fallback in Tomcat
>>>
>>> Hi everyone,
>>>
>>> I know this issue has been raised a couple times already, so sorry for
>>> reposting it. I can't figure out how to resolve this even after reading
>>> through pretty much anything I've found on the issue.
>>>
>>> The problem is the following warning in my server's log file:
>>>
>>> 2011-09-16 12:00:36,623 [http-8080-exec-1] WARN
>>> org.atmosphere.cpr.AtmosphereServlet - failed using comet support:
>>> org.atmosphere.container.TomcatCometSupport, error: Tomcat failed to
>>> detect this is a Comet application because context.xml is missing or
>>> the Http11NioProtocol Connector is not enabled.
>>> If that's not the case, you can also remove META-INF/context.xml and
>>> WEB-INF/lib/atmosphere-compat-tomcat.jar
>>> 2011-09-16 12:00:36,625 [http-8080-exec-1] WARN
>>> org.atmosphere.cpr.AtmosphereServlet - Using BlockingIOCometSupport.
>>>
>>> I am using version 0.7.1 of Atmosphere in combination with the Guice
>>> integration module (atmosphere-guice) as well as the Google Web Toolkit
>>> (GWT) integration (atmosphere-gwt-common, atmosphere-gwt-client,
>>> atmosphere-gwt-server, atmosphere-gwt-poll). There are also the
>>> atmosphere-runtime (obviously), the atmosphere-jersey and the
>>> atmosphere-annotations JARs on my classpath but they shouldn't be in
>>> use (except by Atmosphere internally).
>>>
>>> What have I done so far:
>>>
>>> 0) I have tried getting it to work on Tomcat 7 (v7.0.21) and Tomcat 6
>>> (v6.0.33); on Tomcat 7 I also can't get it to use Servlet 3.0 (maybe
>>> because GWT requires me to specify the web module to be a version 2.5
>>> module)
>>> 1) I have enabled the Http11NioProtocol Connnector in my Tomcat
>>> server.xml configuration.
>>> 2) I have removed the "atmosphere-compat-tomcat-0.7.1.jar" from
>>> WEB-INF/lib since it contains fake classes only. (this only works for
>>> Tomcat 6 since Tomcat 7 requires the fake classes from the JAR because
>>> it appears that the namespaces for Tomcat's Comet types have changed)
>>> 3) I have tried removing the META-INF/context.xml to no avail.
>>> 4) I have tried adding<Loader delegate="true"/>    to
>>> META-INF/context.xml
>>>
>>> I think my issue has to do with the fact that I am using the Guice
>>> integration (or the GWT integration).
>>>
>>> The only thread I've found/read that deals with resolving something
>>> similar is this one:
>>> http://atmosphere-users-mailling-list.2493822.n2.nabble.com/New-Guice-i
>>> ntegration-always-uses-blocking-IO-on-Tomcat-td4469089.html
>>>
>>> I've noticed that the fix proposed there is included in the
>>> AtmosphereGuiceServlet class as well as the
>>> GuiceManagedAtmosphereServlet class. The code in the method
>>> detectSupportedFramework() is however never called in my case since I
>>> supply an atmosphere.xml that defines one dummy handler that I
>>> programmatically remove before programmatically adding my own handler
>>> (I do this adding of the atmosphere handler programmatically because
>>> the handler itself is constructed by Guice since it depends on some
>>> other application classes that are injected to its constructor; if I
>>> don't do it this way, it blows up at creation time since the handler
>>> does not define a default constructor). Could this be somehow related
>>> to my problem? (Sorry, I've been getting slightly confused over the
>>> past 3 hours)
>>>
>>> Does anyone have any additional hints what I could try in order to
>>> activate the non-blocking support for Tomcat?
>>>
>>> Would greatly appreciate any help, thanks a lot!
>>>
>>> - Mark
Reply | Threaded
Open this post in threaded view
|

[atmosphere-users] Re: [] Re: Can't get rid of the BlockIOCometSupport fallback in Tomcat

Jeanfrancois Arcand-4
Salut,

switching mailing list to: [hidden email]

On 11-09-22 6:05 AM, Mark Heimann wrote:
> 3. We needed to change some of our application code in relation to Atmosphere because of API changes in Atmosphere 0.8 (no big deals though; getBroadcaster(...) changed it's behavior and gave us some NullReferenceExceptions).
Can you cut & paste the exception? For sure this is a regression.

>
> It's also worth mentioning that (I think) it's no longer necessary to remove the atmosphere-compat-tomcat-XXX.jar when the loader delegation is activated (point 2 above). If you now want to deploy this in Tomcat 6 you also need to supply the "org.atmosphere.cpr.cometSupport" init parameter because Tomcat7CometSupport seems to be the default and it throws some errors if you don't do that, snippet from the web.xml looks as follows:
>
> <init-param>
>      <param-name>org.atmosphere.cpr.cometSupport</param-name>
>      <param-value>org.atmosphere.container.TomcatCometSupport</param-value>
> </init-param>
Hum that shouldn't happens. I will do some test to see why Tomcat 7 is
detected in Tomcat 6. That is a regression as well if that's true.

Thanks!

-- Jeanfrancois

Reply | Threaded
Open this post in threaded view
|

[atmosphere-users] Re: [] Re: Can't get rid of the BlockIOCometSupport fallback in Tomcat

Mark H
Ehrm,

it's the getBroadcaster() method in AtmosphereGwtHandler, it's now deprecated in 0.8-SNAPSHOT. Before it would look up the default broadcaster when you supplied null as resource parameter, i.e. getBroadcaster(null). Now it will always try to retrieve the broadcaster from the supplied GwtAtmosphereResource.

Personally I'd like to have a helper method for retrieving the broadcaster without supplying a resource because we sometimes need to broadcast messages to all connected clients. I'm not sure whether it makes sense in general because you could have multiple broadcasters (in the case of Atmosphere's GWT module, every resource gets the same broadcast, so there really is only one).

I'll see if I can get you the exception that was thrown when not supplying the cometSupport parameter and deploying in Tomcat 6.

Cheers,
Mark

----- Ursprüngliche Mail -----
Von: "Jeanfrancois Arcand" <[hidden email]>
An: [hidden email], [hidden email]
Gesendet: Donnerstag, 22. September 2011 14:08:09
Betreff: [atmosphere-users] Re: [] Re: Can't get rid of the BlockIOCometSupport fallback in Tomcat

Salut,

switching mailing list to: [hidden email]

On 11-09-22 6:05 AM, Mark Heimann wrote:
> 3. We needed to change some of our application code in relation to Atmosphere because of API changes in Atmosphere 0.8 (no big deals though; getBroadcaster(...) changed it's behavior and gave us some NullReferenceExceptions).
Can you cut & paste the exception? For sure this is a regression.

>
> It's also worth mentioning that (I think) it's no longer necessary to remove the atmosphere-compat-tomcat-XXX.jar when the loader delegation is activated (point 2 above). If you now want to deploy this in Tomcat 6 you also need to supply the "org.atmosphere.cpr.cometSupport" init parameter because Tomcat7CometSupport seems to be the default and it throws some errors if you don't do that, snippet from the web.xml looks as follows:
>
> <init-param>
>      <param-name>org.atmosphere.cpr.cometSupport</param-name>
>      <param-value>org.atmosphere.container.TomcatCometSupport</param-value>
> </init-param>
Hum that shouldn't happens. I will do some test to see why Tomcat 7 is
detected in Tomcat 6. That is a regression as well if that's true.

Thanks!

-- Jeanfrancois

Reply | Threaded
Open this post in threaded view
|

[atmosphere-users] Re: [] Re: Can't get rid of the BlockIOCometSupport fallback in Tomcat

Mark H
Forget about this cometSupport thing, it works correctly without supplying it. I guess I got confused yesterday :).

Thanks,
Mark

----- Ursprüngliche Mail -----
Von: "Mark Heimann" <[hidden email]>
An: [hidden email]
Gesendet: Freitag, 23. September 2011 11:28:40
Betreff: Re: [atmosphere-users] Re: [] Re: Can't get rid of the BlockIOCometSupport fallback in Tomcat

Ehrm,

it's the getBroadcaster() method in AtmosphereGwtHandler, it's now deprecated in 0.8-SNAPSHOT. Before it would look up the default broadcaster when you supplied null as resource parameter, i.e. getBroadcaster(null). Now it will always try to retrieve the broadcaster from the supplied GwtAtmosphereResource.

Personally I'd like to have a helper method for retrieving the broadcaster without supplying a resource because we sometimes need to broadcast messages to all connected clients. I'm not sure whether it makes sense in general because you could have multiple broadcasters (in the case of Atmosphere's GWT module, every resource gets the same broadcast, so there really is only one).

I'll see if I can get you the exception that was thrown when not supplying the cometSupport parameter and deploying in Tomcat 6.

Cheers,
Mark

----- Ursprüngliche Mail -----
Von: "Jeanfrancois Arcand" <[hidden email]>
An: [hidden email], [hidden email]
Gesendet: Donnerstag, 22. September 2011 14:08:09
Betreff: [atmosphere-users] Re: [] Re: Can't get rid of the BlockIOCometSupport fallback in Tomcat

Salut,

switching mailing list to: [hidden email]

On 11-09-22 6:05 AM, Mark Heimann wrote:
> 3. We needed to change some of our application code in relation to Atmosphere because of API changes in Atmosphere 0.8 (no big deals though; getBroadcaster(...) changed it's behavior and gave us some NullReferenceExceptions).
Can you cut & paste the exception? For sure this is a regression.

>
> It's also worth mentioning that (I think) it's no longer necessary to remove the atmosphere-compat-tomcat-XXX.jar when the loader delegation is activated (point 2 above). If you now want to deploy this in Tomcat 6 you also need to supply the "org.atmosphere.cpr.cometSupport" init parameter because Tomcat7CometSupport seems to be the default and it throws some errors if you don't do that, snippet from the web.xml looks as follows:
>
> <init-param>
>      <param-name>org.atmosphere.cpr.cometSupport</param-name>
>      <param-value>org.atmosphere.container.TomcatCometSupport</param-value>
> </init-param>
Hum that shouldn't happens. I will do some test to see why Tomcat 7 is
detected in Tomcat 6. That is a regression as well if that's true.

Thanks!

-- Jeanfrancois