[ https://issues.apache.org/jira/browse/TOMEE-2108?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16116152#comment-16116152 ]
Svetlin Zarev commented on TOMEE-2108: -------------------------------------- Given my previous comment, I don't think that TomEEContainer can actually do the clean up. The proper solution would be the Tomcat WebAppBuilder to properly clean up after failed deployment -> TOMEE-2098 > TomEEContainer (arquillian) does not clean up after failed deployment. > ---------------------------------------------------------------------- > > Key: TOMEE-2108 > URL: https://issues.apache.org/jira/browse/TOMEE-2108 > Project: TomEE > Issue Type: Bug > Reporter: Svetlin Zarev > > h4. Problem: > --- > When the deployment fails, the DeployerEjb throws javax.ejb.EjbException and > the "archiveName" is not added to "moduleIds". As a result when > undeploy(Archive) is called, the associated DeployedApp is not found and > clean up is not performed -> this results in tomcat's internal structures > still keeping data for the failed webapp, which might break other > (re)deployments with the same webapp name. > h4. Steps to reproduce: > --- > Execute any of the CDI TCK test that are expected to fail. I tested with > (passing.xml): > {code} > <test name="JSR-346 TCK"> > <classes> > <class > name="org.jboss.cdi.tck.tests.decorators.definition.broken.nodecoratedtypes.DecoratorWithNoDecoratedTypes1Test"/> > > <class > name="org.jboss.cdi.tck.tests.decorators.definition.broken.nodecoratedtypes.DecoratorWithNoDecoratedTypes2Test"/> > > </classes> > </test> > {code} > The classes are deployed sequentally using the same war name. Both > deployments will fail as expected. After undeploy is called for teh first > one, a WARN message is logged: > {code} > VIII 04, 2017 9:59:47 PM org.apache.openejb.arquillian.common.TomEEContainer > undeploy > WARNING: 2fea4e92ef1679e3f8eaf0cc2ce557a56f68cb26.war was not deployed > {code} > So far so good, the deployment failed, so we might assume it was not really > deployed and dismiss the warning. Unfortunately Tomcat did never perform a > clean up for that app, so when the next test is deployed (with the same WAR > name) we can see in the logs: > {code} > 04-Aug-2017 21:59:47.233 SEVERE [http-nio-35825-exec-5] > sun.reflect.NativeMethodAccessorImpl.invoke Creation of the naming context > failed: [javax.naming.OperationNotSupportedException: Context is read only] > {code} > That's not what we expected to see. This happens because in > org.apache.naming.ContextAccessController#setSecurityToken, when the security > token is being associated with the context name, it checks only if a token > exists for that name, but not if it's thE same token: > {code} > public static void setSecurityToken(Object name, Object token) { > SecurityManager sm = System.getSecurityManager(); > if (sm != null) { > sm.checkPermission(new RuntimePermission( > ContextAccessController.class.getName() > + ".setSecurityToken")); > } > if ((!securityTokens.containsKey(name)) && (token != null)) { > securityTokens.put(name, token); > } > } > {code} > And the root cause for that is that no clean up was performed (kind of > related to: TOMEE-2098). > h4. Proposal: > --- > Do clean up if the deployment fails. This would be as simple as adding > catch(EjbException) in > org.apache.openejb.arquillian.common.TomEEContainer#deploy(org.jboss.shrinkwrap.api.Archive<?>): > {code} > } catch (OpenEJBException | EJBException re) { // clean up in undeploy needs > it > moduleIds.put(archiveName, new DeployedApp(file.getAbsolutePath(), file)); > re; > } > {code} > Note that I've changed it to use the absolute path, because otherwise the > ProvisioningResolver is not able to understand the relative path: > {code} > 04-Aug-2017 22:47:42.436 SEVERE [http-nio-42119-exec-9] > org.apache.openejb.core.transaction.EjbTransactionUtil.handleSystemException > EjbTransactionUtil.handleSystemException: Not a local file but no prefix > specified: target/workdir/1/2fea4e92ef1679e3f8eaf0cc2ce557a56f68cb26.war. So > can't resolve > java.lang.IllegalArgumentException: Not a local file but no prefix > specified: target/workdir/1/2fea4e92ef1679e3f8eaf0cc2ce557a56f68cb26.war. So > can't resolve > at > org.apache.openejb.loader.provisining.ProvisioningResolver.protocol(ProvisioningResolver.java:133) > at > org.apache.openejb.loader.provisining.ProvisioningResolver.realLocation(ProvisioningResolver.java:115) > at > org.apache.openejb.loader.ProvisioningUtil.realLocation(ProvisioningUtil.java:158) > at > org.apache.openejb.assembler.classic.Assembler.getAppInfo(Assembler.java:633) > at > org.apache.openejb.assembler.DeployerEjb.undeploy(DeployerEjb.java:410) > {code} > The issue is that the resolver cannot correctly resolve the absolute path > from the relative one. It thinks it is: > {code} > /home/svetlin/git/open-source/tomee/tck/cdi-tomee/target/tomee/apache-tomee-plus-7.0.4-SNAPSHOT/target/workdir/0/2fea4e92ef1679e3f8eaf0cc2ce557a56f68cb26.war > {code} > While it really is: > {code} > /home/svetlin/git/open-source/tomee/tck/cdi-tomee/target/workdir/0/2fea4e92ef1679e3f8eaf0cc2ce557a56f68cb26.war > {code} > h4. Summary > --- > * when the deployment fails, no clean up is done > * do clean up after failed deplyments > ** catch javax.ejb.EjbException besides OpenEjbException > ** Use absolute path for DeployedApp.path in case of failed deployment > What do you think ? -- This message was sent by Atlassian JIRA (v6.4.14#64029)