[
https://issues.apache.org/jira/browse/TOMEE-2108?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16116160#comment-16116160
]
Svetlin Zarev commented on TOMEE-2108:
--------------------------------------
[~rmannibucau] Hi,
The undeploy-on-failure is no really working on tomcat's side, because if the
deployment fails, the app is in STARTING_PREP. So when undeploying from tomcat,
it logs an error and does nothing.
> 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)
