will connect on IRC now but this was working for sure since I fixed it twice working on TCKs
Romain Manni-Bucau @rmannibucau <https://twitter.com/rmannibucau> | Blog <http://rmannibucau.wordpress.com> | Github <https://github.com/rmannibucau> | LinkedIn <https://www.linkedin.com/in/rmannibucau> | Tomitriber <http://www.tomitribe.com> 2015-05-16 18:04 GMT+02:00 Mark Struberg <strub...@yahoo.de>: > Btw this TCK test also blurps up in master, but weirdly it seems to pass: > > INFO: Invoke > SessionContextAsyncListenerTest.testSessionContextActiveOnError: 273/1,494 > (124) > May 15, 2015 2:03:56 PM com.gargoylesoftware.htmlunit.WebClient > printContentIfNecessary > INFO: statusCode=[500] contentType=[text/html] > SEVERE - ERROR_0013 > java.lang.IllegalStateException: Cannot create a session after the > response has been committed > at > org.apache.catalina.connector.Request.doGetSession(Request.java:2877) > at > org.apache.catalina.connector.Request.getSession(Request.java:2254) > at > org.apache.catalina.connector.RequestFacade.getSession(RequestFacade.java:895) > at > org.apache.catalina.connector.RequestFacade.getSession(RequestFacade.java:907) > at > org.apache.openejb.cdi.CdiAppContextsService.lazyStartSessionContext(CdiAppContextsService.java:736) > at > org.apache.openejb.cdi.CdiAppContextsService.getSessionContext(CdiAppContextsService.java:680) > at > org.apache.openejb.cdi.CdiAppContextsService.getCurrentContext(CdiAppContextsService.java:277) > at > org.apache.webbeans.container.BeanManagerImpl.getContext(BeanManagerImpl.java:294) > at > org.apache.webbeans.intercept.NormalScopedBeanInterceptorHandler.getContextualInstance(NormalScopedBeanInterceptorHandler.java:88) > at > org.apache.webbeans.intercept.NormalScopedBeanInterceptorHandler.get(NormalScopedBeanInterceptorHandler.java:70) > at > org.jboss.cdi.tck.tests.context.session.async.SimpleSessionBean$$OwbNormalScopeProxy0.getId(org/jboss/cdi/tck/tests/context/session/async/SimpleSessionBean.java) > at > org.jboss.cdi.tck.tests.context.session.async.SimpleAsyncListener.checkSessionContextAvailability(SimpleAsyncListener.java:99) > at > org.jboss.cdi.tck.tests.context.session.async.SimpleAsyncListener.onError(SimpleAsyncListener.java:82) > at > org.apache.openejb.server.httpd.WebBeansFilter$AsynContextWrapper$ScopeAwareListener.onError(WebBeansFilter.java:233) > at > org.apache.catalina.core.AsyncListenerWrapper.fireOnError(AsyncListenerWrapper.java:45) > at > org.apache.catalina.core.AsyncContextImpl.setErrorState(AsyncContextImpl.java:415) > at > org.apache.catalina.connector.CoyoteAdapter.asyncDispatch(CoyoteAdapter.java:394) > at > org.apache.coyote.http11.AbstractHttp11Processor.asyncDispatch(AbstractHttp11Processor.java:1709) > at > org.apache.coyote.AbstractProtocol$AbstractConnectionHandler.process(AbstractProtocol.java:649) > at > org.apache.tomcat.util.net.NioEndpoint$SocketProcessor.doRun(NioEndpoint.java:1521) > at > org.apache.tomcat.util.net.NioEndpoint$SocketProcessor.run(NioEndpoint.java:1478)May > 15, 2015 2:03:56 PM com.gargoylesoftware.htmlunit.WebClient > printContentIfNecessary > INFO: <!DOCTYPE html><html><head><title>Apache Tomcat (TomEE)/8.0.22 > (7.0.0-SNAPSHOT) - Error report</title><style type="text/css">H1 > {font-family:Tahoma,Arial,sans-serif;color:white;background-color:#525D76;font-size:22px;} > H2 > {font-family:Tahoma,Arial,sans-serif;color:white;background-color:#525D76;font-size:16px;} > H3 > {font-family:Tahoma,Arial,sans-serif;color:white;background-color:#525D76;font-size:14px;} > BODY > {font-family:Tahoma,Arial,sans-serif;color:black;background-color:white;} B > {font-family:Tahoma,Arial,sans-serif;color:white;background-color:#525D76;} > P > {font-family:Tahoma,Arial,sans-serif;background:white;color:black;font-size:12px;}A > {color : black;}A.name {color : black;}.line {height: 1px; > background-color: #525D76; border: none;}</style> </head><body><h1>HTTP > Status 500 - </h1><div class="line"></div><p><b>type</b> Exception > report</p><p><b>message</b> <u></u></p><p><b>description</b> <u>The server > encountered an internal error that prevented it from fulfilling this > request.</u></p><p><b>exception</b></p><pre>javax.servlet.ServletException > > org.jboss.cdi.tck.tests.context.session.async.FailingServlet.service(FailingServlet.java:38) > javax.servlet.http.HttpServlet.service(HttpServlet.java:729) > </pre><p><b>note</b> <u>The full stack trace of the root cause is > available in the Apache Tomcat (TomEE)/8.0.22 (7.0.0-SNAPSHOT) > logs.</u></p><hr class="line"><h3>Apache Tomcat (TomEE)/8.0.22 > (7.0.0-SNAPSHOT)</h3></body></html> > > at > java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) > at > java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) > at > org.apache.tomcat.util.threads.TaskThread$WrappingRunnable.run(TaskThread.java:61) > at java.lang.Thread.run(Thread.java:745) > May 15, 2015 2:03:56 PM > org.jboss.cdi.tck.impl.testng.ProgressLoggingTestListener beforeInvocation > INFO: Invoke > SessionContextAsyncListenerTest.testSessionContextActiveOnStartAsync: > 274/1,494 (124) > WARNING - Could NOT lazily initialize session context because NO active > request context > May 15, 2015 2:03:56 PM > org.jboss.cdi.tck.impl.testng.ProgressLoggingTestListener beforeInvocation > INFO: Invoke > SessionContextAsyncListenerTest.testSessionContextActiveOnTimeout: > 275/1,494 (124) > May 15, 2015 2:03:57 PM org.apache.openejb.client.EventLogger log > INFO: RemoteInitialContextCreated{providerUri= > http://localhost:42292/tomee/ejb} > > > The current master also is like a Chameleon. It changes from red to green > and back in just a mere single build ;) > Means the outcome is currently pretty weird. We need to review why this > happens. One of those tests is because of the sleep period of 3s in the TCK > tests is probably too low to give reliable tests. > > Will propagate the stuff to master now. > > LieGrue, > strub > > > > Am 16.05.2015 um 17:52 schrieb Mark Struberg <strub...@yahoo.de>: > > > > debugged this in master as well and it is also broken. > > I guess we just didn’t detect this as in the old OWB version we simply > cleaned out all SessionContexts we maintained in a HashMap. > > But in OWB-1.6.0 we now use the real HttpSession so we fail to clean > this up properly. > > > > With other words: it was broken ever since, but we simply didn’t have a > test hitting this use case. > > > > LieGrue, > > strub > > > >> Am 16.05.2015 um 15:55 schrieb Romain Manni-Bucau < > rmannibu...@gmail.com>: > >> > >> Le 16 mai 2015 15:12, "Mark Struberg" <strub...@yahoo.de> a écrit : > >>> > >>> And yet a bit more info. > >>> > >>> What happens when an app is undeployed using Arquillian then > >>> > >>> 1.) the CDI container (OpenEJBLifecycle implements > >> ContainerLifecycle#stop) gets shut down. This will also stop the > contexts > >> it has access to. That does NOT include SessionContexts anymore… > >>> > >> > >> Why, was the case? With your refactoring you mean? > >> > >>> 2.) the webapp gets undeployed from Tomcat. This happens in > >> TomcatWebAppBuilder#undeploy(final StandardContext standardContext, > final > >> Container host). > >>> Please note that the webapp in question _still_ has the state STARTED. > By > >> invoking host.removeChild(standardContext); we just remove the context > >> information from Tomcat but this seems NOT to properly stop the > application > >> it seems! > >>> > >> > >> Dont 100% recall but can be async. Breakpoint in > >> StandardContext#stopInternal > >> > >>> LieGrue, > >>> strub > >>> > >>>> Am 16.05.2015 um 14:42 schrieb Mark Struberg <strub...@yahoo.de>: > >>>> > >>>> when using arquillian that seems not to be the case afaics. > >>>> > >>>> openejb Assembler#destroyApplication(final AppInfo appInfo) just looks > >> up the WebBeansLifecycle from OpenWebBeans and shuts it down. By doing > this > >> it will also destroy the various contexts. But this does _not_ destroy > any > >> _real_ SessionContexts anymore (but only ’synthetic’ HashMap backed > ones). > >> It seems it also doesn’t invoke _any_ > HttpSessionListener#sessionDestroyed > >> during undeploy of an arquillian webapp. Thus I assume that the webapp > >> doesn’t get properly undeployed from Tomcat. But this is not really an > area > >> where I’m really good in, so I probably missed something. > >>>> > >>>> LieGrue, > >>>> strub > >>>> > >>>>> Am 16.05.2015 um 13:24 schrieb Romain Manni-Bucau < > >> rmannibu...@gmail.com>: > >>>>> > >>>>> Normal undeployment will call tomcat one. Same way as we have to > >> support > >>>>> for ears so important to have it working this way. > >>>>> Le 16 mai 2015 12:40, "Mark Struberg" <strub...@yahoo.de> a écrit : > >>>>> > >>>>>> Just saw that my sentence is very ambiguous. > >>>>>> Of course the undeploy is perfectly fine IF we just use the standard > >>>>>> tomcat deploy/undeploy. But we do not cleanly undeploy via > Arquillian > >>>>>> (which is used in the TCK). > >>>>>> > >>>>>> LieGrue, > >>>>>> strub > >>>>>> > >>>>>>> Am 16.05.2015 um 11:38 schrieb Mark Struberg <strub...@yahoo.de>: > >>>>>>> > >>>>>>> Hi! > >>>>>>> > >>>>>>> We have 2 TCK tests (of the last 4 failing ones) who test the > >> undeploy > >>>>>> scenario. They fail as they rely on a clean undeploy - which we do > >> not do > >>>>>> atm it seems. > >>>>>>> > >>>>>>> In DeployerEJB we do a clean deploy via WebAppDeployer#deploy(). > This > >>>>>> creates the Tomcat Context and starts the webapp. But this seems to > >> miss an > >>>>>> undeploy(). The result is that any contextDestroyed servlet Listener > >> will > >>>>>> not get triggered. > >>>>>>> Anything I miss? > >>>>>>> > >>>>>>> LieGrue, > >>>>>>> strub > >>>>>> > >>>>>> > >>>> > >>> > > > >
