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