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