tomee-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Svetlin Zarev (JIRA)" <j...@apache.org>
Subject [jira] [Updated] (TOMEE-2108) TomEEContainer (arquillian) does not clean up after failed deployment.
Date Fri, 04 Aug 2017 20:14:00 GMT

     [ https://issues.apache.org/jira/browse/TOMEE-2108?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]

Svetlin Zarev updated TOMEE-2108:
---------------------------------
    Description: 
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
strucutures still keeping data for the faild webapp, which might break other (re)deployments
wuth 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 faild, 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. 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 ? 


  was:
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
strucutures still keeping data for the faild webapp, which might break other (re)deployments
wuth 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 faild, 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<?>):
} 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. 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 ? 



> 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
strucutures still keeping data for the faild webapp, which might break other (re)deployments
wuth 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 faild, 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. 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)

Mime
View raw message