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 <[email protected]>:
>
> 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 <[email protected]>:
>>
>> Le 16 mai 2015 15:12, "Mark Struberg" <[email protected]> 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 <[email protected]>:
>>>>
>>>> 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 <
>> [email protected]>:
>>>>>
>>>>> 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" <[email protected]> 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 <[email protected]>:
>>>>>>>
>>>>>>> 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
>>>>>>
>>>>>>
>>>>
>>>
>
