New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

WELD-1581 Add ServletContainerInitializer-based listener for servlet env... #465

Closed
wants to merge 2 commits into
base: master
from

Conversation

Projects
None yet
4 participants
@mkouba
Member

mkouba commented Jan 28, 2014

...ironment

@weld-tester

This comment has been minimized.

Show comment
Hide comment

weld-tester commented Jan 28, 2014

Triggering build using a merge of 04e427b on branch master:
Private: https://jenkins.mw.lab.eng.bos.redhat.com/hudson/job/Weld-2.x-pull-player-executor/

@weld-tester

This comment has been minimized.

Show comment
Hide comment
@weld-tester

weld-tester commented Jan 28, 2014

Build 296 is now running using a merge of 04e427b on branch master:
Private: https://jenkins.mw.lab.eng.bos.redhat.com/hudson/job/Weld-2.x-pull-player-executor/296

@weld-tester

This comment has been minimized.

Show comment
Hide comment
@jharting

This comment has been minimized.

Show comment
Hide comment
@jharting

jharting Jan 29, 2014

Member

retest this please

Member

jharting commented Jan 29, 2014

retest this please

@weld-tester

This comment has been minimized.

Show comment
Hide comment

weld-tester commented Jan 29, 2014

Triggering build using a merge of 04e427b on branch master:
Private: https://jenkins.mw.lab.eng.bos.redhat.com/hudson/job/Weld-2.x-pull-player-executor/

@weld-tester

This comment has been minimized.

Show comment
Hide comment
WELD-1581 Add EnhancedListenerTest
- workaround Tomcat embedded and Maven Surefire classloading issue
- upgrade Tomcat 7.x version to 7.0.50
@weld-tester

This comment has been minimized.

Show comment
Hide comment

weld-tester commented Jan 29, 2014

Triggering build using a merge of 62a892f on branch master:
Private: https://jenkins.mw.lab.eng.bos.redhat.com/hudson/job/Weld-2.x-pull-player-executor/

@weld-tester

This comment has been minimized.

Show comment
Hide comment
@weld-tester

weld-tester commented Jan 29, 2014

Build 301 is now running using a merge of 62a892f on branch master:
Private: https://jenkins.mw.lab.eng.bos.redhat.com/hudson/job/Weld-2.x-pull-player-executor/301

@KlausBrunner

This comment has been minimized.

Show comment
Hide comment
@KlausBrunner

KlausBrunner Jan 29, 2014

Just like the original pull request from @janbartel , this works well enough for my simple test app on the latest Jetty release (9.1.1.v20140108), however I'm getting a bunch of ugly messages on server shutdown or application undeployment trying to use an injected bean in ServletContextListener.contextDestroyed():

2014-01-29 14:08:45.280:WARN:oejuc.AbstractLifeCycle:Thread-0: FAILED o.e.j.w.WebAppContext@223b9f2b{/cditest,file:/tmp/jetty-0.0.0.0-8080-cditest.war-_cditest-any-3641048160779826144.dir/webapp/,UNAVAILABLE}{/cditest.war}: java.lang.IllegalStateException: Singleton is not set. Is your Thread.currentThread().getContextClassLoader() set correctly?
java.lang.IllegalStateException: Singleton is not set. Is your Thread.currentThread().getContextClassLoader() set correctly?
    at org.jboss.weld.bootstrap.api.helpers.IsolatedStaticSingletonProvider$IsolatedStaticSingleton.get(IsolatedStaticSingletonProvider.java:47)
    at org.jboss.weld.Container.instance(Container.java:65)
    at org.jboss.weld.bean.proxy.ContextBeanInstance.getInstance(ContextBeanInstance.java:75)
    at org.jboss.weld.bean.proxy.ProxyMethodHandler.invoke(ProxyMethodHandler.java:78)
    at test.MessagesBean$Proxy$_$$_WeldClientProxy.addMessage(Unknown Source)
    at test.ContextListener.contextDestroyed(ContextListener.java:32)
    at org.eclipse.jetty.server.handler.ContextHandler.callContextDestroyed(ContextHandler.java:806)
    at org.eclipse.jetty.servlet.ServletContextHandler.callContextDestroyed(ServletContextHandler.java:459)
    at org.eclipse.jetty.server.handler.ContextHandler.doStop(ContextHandler.java:840)
    at org.eclipse.jetty.servlet.ServletContextHandler.doStop(ServletContextHandler.java:217)
    at org.eclipse.jetty.webapp.WebAppContext.doStop(WebAppContext.java:516)
    at org.eclipse.jetty.util.component.AbstractLifeCycle.stop(AbstractLifeCycle.java:90)
    at org.eclipse.jetty.util.component.ContainerLifeCycle.stop(ContainerLifeCycle.java:128)
    at org.eclipse.jetty.util.component.ContainerLifeCycle.doStop(ContainerLifeCycle.java:147)
    at org.eclipse.jetty.server.handler.AbstractHandler.doStop(AbstractHandler.java:71)
    at org.eclipse.jetty.util.component.AbstractLifeCycle.stop(AbstractLifeCycle.java:90)
    at org.eclipse.jetty.util.component.ContainerLifeCycle.stop(ContainerLifeCycle.java:128)
    at org.eclipse.jetty.util.component.ContainerLifeCycle.doStop(ContainerLifeCycle.java:147)
    at org.eclipse.jetty.server.handler.AbstractHandler.doStop(AbstractHandler.java:71)
    at org.eclipse.jetty.util.component.AbstractLifeCycle.stop(AbstractLifeCycle.java:90)
    at org.eclipse.jetty.util.component.ContainerLifeCycle.stop(ContainerLifeCycle.java:128)
    at org.eclipse.jetty.util.component.ContainerLifeCycle.doStop(ContainerLifeCycle.java:147)
    at org.eclipse.jetty.server.handler.AbstractHandler.doStop(AbstractHandler.java:71)
    at org.eclipse.jetty.server.Server.doStop(Server.java:423)
    at org.eclipse.jetty.util.component.AbstractLifeCycle.stop(AbstractLifeCycle.java:90)
    at org.eclipse.jetty.util.thread.ShutdownThread.run(ShutdownThread.java:132)

So it looks like stuff is torn down before contextDestroyed() is called, but I'm not sure whether that's a fault of Jetty or Weld.

KlausBrunner commented Jan 29, 2014

Just like the original pull request from @janbartel , this works well enough for my simple test app on the latest Jetty release (9.1.1.v20140108), however I'm getting a bunch of ugly messages on server shutdown or application undeployment trying to use an injected bean in ServletContextListener.contextDestroyed():

2014-01-29 14:08:45.280:WARN:oejuc.AbstractLifeCycle:Thread-0: FAILED o.e.j.w.WebAppContext@223b9f2b{/cditest,file:/tmp/jetty-0.0.0.0-8080-cditest.war-_cditest-any-3641048160779826144.dir/webapp/,UNAVAILABLE}{/cditest.war}: java.lang.IllegalStateException: Singleton is not set. Is your Thread.currentThread().getContextClassLoader() set correctly?
java.lang.IllegalStateException: Singleton is not set. Is your Thread.currentThread().getContextClassLoader() set correctly?
    at org.jboss.weld.bootstrap.api.helpers.IsolatedStaticSingletonProvider$IsolatedStaticSingleton.get(IsolatedStaticSingletonProvider.java:47)
    at org.jboss.weld.Container.instance(Container.java:65)
    at org.jboss.weld.bean.proxy.ContextBeanInstance.getInstance(ContextBeanInstance.java:75)
    at org.jboss.weld.bean.proxy.ProxyMethodHandler.invoke(ProxyMethodHandler.java:78)
    at test.MessagesBean$Proxy$_$$_WeldClientProxy.addMessage(Unknown Source)
    at test.ContextListener.contextDestroyed(ContextListener.java:32)
    at org.eclipse.jetty.server.handler.ContextHandler.callContextDestroyed(ContextHandler.java:806)
    at org.eclipse.jetty.servlet.ServletContextHandler.callContextDestroyed(ServletContextHandler.java:459)
    at org.eclipse.jetty.server.handler.ContextHandler.doStop(ContextHandler.java:840)
    at org.eclipse.jetty.servlet.ServletContextHandler.doStop(ServletContextHandler.java:217)
    at org.eclipse.jetty.webapp.WebAppContext.doStop(WebAppContext.java:516)
    at org.eclipse.jetty.util.component.AbstractLifeCycle.stop(AbstractLifeCycle.java:90)
    at org.eclipse.jetty.util.component.ContainerLifeCycle.stop(ContainerLifeCycle.java:128)
    at org.eclipse.jetty.util.component.ContainerLifeCycle.doStop(ContainerLifeCycle.java:147)
    at org.eclipse.jetty.server.handler.AbstractHandler.doStop(AbstractHandler.java:71)
    at org.eclipse.jetty.util.component.AbstractLifeCycle.stop(AbstractLifeCycle.java:90)
    at org.eclipse.jetty.util.component.ContainerLifeCycle.stop(ContainerLifeCycle.java:128)
    at org.eclipse.jetty.util.component.ContainerLifeCycle.doStop(ContainerLifeCycle.java:147)
    at org.eclipse.jetty.server.handler.AbstractHandler.doStop(AbstractHandler.java:71)
    at org.eclipse.jetty.util.component.AbstractLifeCycle.stop(AbstractLifeCycle.java:90)
    at org.eclipse.jetty.util.component.ContainerLifeCycle.stop(ContainerLifeCycle.java:128)
    at org.eclipse.jetty.util.component.ContainerLifeCycle.doStop(ContainerLifeCycle.java:147)
    at org.eclipse.jetty.server.handler.AbstractHandler.doStop(AbstractHandler.java:71)
    at org.eclipse.jetty.server.Server.doStop(Server.java:423)
    at org.eclipse.jetty.util.component.AbstractLifeCycle.stop(AbstractLifeCycle.java:90)
    at org.eclipse.jetty.util.thread.ShutdownThread.run(ShutdownThread.java:132)

So it looks like stuff is torn down before contextDestroyed() is called, but I'm not sure whether that's a fault of Jetty or Weld.

@mkouba

This comment has been minimized.

Show comment
Hide comment
@mkouba

mkouba Jan 29, 2014

Member

@KlausBrunner yes, this will not work because EnhancedListener registers itself as the last ServletContextListener and so its contextDestroyed() is invoked as the first one.
Unfortunately there is no way to change this in Servlet 3.1 API, see also ServletContext#addListener.
So for this scenario the old Listener class must be configured in web.xml as well.

Member

mkouba commented Jan 29, 2014

@KlausBrunner yes, this will not work because EnhancedListener registers itself as the last ServletContextListener and so its contextDestroyed() is invoked as the first one.
Unfortunately there is no way to change this in Servlet 3.1 API, see also ServletContext#addListener.
So for this scenario the old Listener class must be configured in web.xml as well.

@weld-tester

This comment has been minimized.

Show comment
Hide comment
@KlausBrunner

This comment has been minimized.

Show comment
Hide comment
@KlausBrunner

KlausBrunner Jan 29, 2014

@mkouba I see; thanks for the explanation. So there's no problem using both this approach and having the Listener registered explicitly in web.xml at the same time?

KlausBrunner commented Jan 29, 2014

@mkouba I see; thanks for the explanation. So there's no problem using both this approach and having the Listener registered explicitly in web.xml at the same time?

@mkouba

This comment has been minimized.

Show comment
Hide comment
@mkouba

mkouba Jan 29, 2014

Member

@KlausBrunner exactly! Mainly to preserve backwards compatibility and also to solve similar ordering problems.

Member

mkouba commented Jan 29, 2014

@KlausBrunner exactly! Mainly to preserve backwards compatibility and also to solve similar ordering problems.

@jharting

This comment has been minimized.

Show comment
Hide comment
@jharting

jharting Jan 30, 2014

Member

Merged, thanks!

Member

jharting commented Jan 30, 2014

Merged, thanks!

@jharting jharting closed this Jan 30, 2014

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment