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