You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tomee.apache.org by Mark Struberg <st...@yahoo.de> on 2015/05/16 11:38:19 UTC
WebAppDeployer does not support undeploy
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
Re: WebAppDeployer does not support undeploy
Posted by Romain Manni-Bucau <rm...@gmail.com>.
Le 16 mai 2015 14:42, "Mark Struberg" <st...@yahoo.de> a écrit :
>
> when using arquillian that seems not to be the case afaics.
>
Lifecycle is a little bit different but needs to be handled as well - and
both are conform to the spec.
> 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 does but later. I checked it several times in particular with recent
fixes. There is a comment about it in CdiAppContextsService. Issue is we
cant destroy cdi later in this case (also why i like this case be the
default undeploy is if we handle this one we handle the other one more
easily).
> 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.
>
Ah i understand. You hit a good issue and why our contexts service dzstroys
it manually. During destroy session are destroyed but listeners are skipped
by tomcat (there is a flag in tomcat method). I guess it is to support
clusters.
> LieGrue,
> strub
>
> > Am 16.05.2015 um 13:24 schrieb Romain Manni-Bucau <rmannibucau@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" <st...@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 <st...@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
> >>
> >>
>
Re: WebAppDeployer does not support undeploy
Posted by Mark Struberg <st...@yahoo.de>.
Found at least a partial explanation.
The servlet spec indeed does not mandate that sessionDestroyed gets fired on undeploy or shutdown.
Instead tomcat serializes the sessions away to a file and reads it again if you start up the application again. This is indeed a cool feature for 24/7 support as you can ‚ripple-start‘ your application via a round-robin project upgrade (shutdown node 1, redeploy next version of your app, restart node 1, then the same with node 2, etc).
So the current behaviour of TomEE is fine and and backed by the spec. I reported CDITCK-482.
LieGrue,
strub
> Am 16.05.2015 um 18:05 schrieb Romain Manni-Bucau <rm...@gmail.com>:
>
> 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 <st...@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 <st...@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 <
>> rmannibucau@gmail.com>:
>>>>
>>>> Le 16 mai 2015 15:12, "Mark Struberg" <st...@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 <st...@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 <
>>>> rmannibucau@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" <st...@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 <st...@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
>>>>>>>>
>>>>>>>>
>>>>>>
>>>>>
>>>
>>
>>
Re: WebAppDeployer does not support undeploy
Posted by Romain Manni-Bucau <rm...@gmail.com>.
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 <st...@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 <st...@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 <
> rmannibucau@gmail.com>:
> >>
> >> Le 16 mai 2015 15:12, "Mark Struberg" <st...@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 <st...@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 <
> >> rmannibucau@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" <st...@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 <st...@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
> >>>>>>
> >>>>>>
> >>>>
> >>>
> >
>
>
Re: WebAppDeployer does not support undeploy
Posted by Mark Struberg <st...@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 <st...@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 <rm...@gmail.com>:
>>
>> Le 16 mai 2015 15:12, "Mark Struberg" <st...@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 <st...@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 <
>> rmannibucau@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" <st...@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 <st...@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
>>>>>>
>>>>>>
>>>>
>>>
>
Re: WebAppDeployer does not support undeploy
Posted by Mark Struberg <st...@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 <rm...@gmail.com>:
>
> Le 16 mai 2015 15:12, "Mark Struberg" <st...@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 <st...@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 <
> rmannibucau@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" <st...@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 <st...@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
>>>>>
>>>>>
>>>
>>
Re: WebAppDeployer does not support undeploy
Posted by Romain Manni-Bucau <rm...@gmail.com>.
Le 16 mai 2015 15:12, "Mark Struberg" <st...@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 <st...@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 <
rmannibucau@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" <st...@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 <st...@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
> >>>
> >>>
> >
>
Re: WebAppDeployer does not support undeploy
Posted by Mark Struberg <st...@yahoo.de>.
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…
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!
LieGrue,
strub
> Am 16.05.2015 um 14:42 schrieb Mark Struberg <st...@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 <rm...@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" <st...@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 <st...@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
>>>
>>>
>
Re: WebAppDeployer does not support undeploy
Posted by Mark Struberg <st...@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 <rm...@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" <st...@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 <st...@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
>>
>>
Re: WebAppDeployer does not support undeploy
Posted by Romain Manni-Bucau <rm...@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" <st...@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 <st...@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
>
>
Re: WebAppDeployer does not support undeploy
Posted by Mark Struberg <st...@yahoo.de>.
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 <st...@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