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 > >>> > >>> > > >
