Return-Path: X-Original-To: archive-asf-public-internal@cust-asf2.ponee.io Delivered-To: archive-asf-public-internal@cust-asf2.ponee.io Received: from cust-asf.ponee.io (cust-asf.ponee.io [163.172.22.183]) by cust-asf2.ponee.io (Postfix) with ESMTP id F3A41200CDA for ; Fri, 4 Aug 2017 22:14:05 +0200 (CEST) Received: by cust-asf.ponee.io (Postfix) id F1F7516E3C0; Fri, 4 Aug 2017 20:14:05 +0000 (UTC) Delivered-To: archive-asf-public@cust-asf.ponee.io Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by cust-asf.ponee.io (Postfix) with SMTP id EACCB16E3BE for ; Fri, 4 Aug 2017 22:14:04 +0200 (CEST) Received: (qmail 11885 invoked by uid 500); 4 Aug 2017 20:14:03 -0000 Mailing-List: contact commits-help@tomee.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: dev@tomee.apache.org Delivered-To: mailing list commits@tomee.apache.org Received: (qmail 11796 invoked by uid 500); 4 Aug 2017 20:14:03 -0000 Delivered-To: apmail-openejb-commits@openejb.apache.org Received: (qmail 11782 invoked by uid 99); 4 Aug 2017 20:14:03 -0000 Received: from pnap-us-west-generic-nat.apache.org (HELO spamd1-us-west.apache.org) (209.188.14.142) by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 04 Aug 2017 20:14:03 +0000 Received: from localhost (localhost [127.0.0.1]) by spamd1-us-west.apache.org (ASF Mail Server at spamd1-us-west.apache.org) with ESMTP id 5DFC8C2CBC for ; Fri, 4 Aug 2017 20:14:03 +0000 (UTC) X-Virus-Scanned: Debian amavisd-new at spamd1-us-west.apache.org X-Spam-Flag: NO X-Spam-Score: -98.952 X-Spam-Level: X-Spam-Status: No, score=-98.952 tagged_above=-999 required=6.31 tests=[KAM_ASCII_DIVIDERS=0.8, KAM_LOTSOFHASH=0.25, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=disabled Received: from mx1-lw-us.apache.org ([10.40.0.8]) by localhost (spamd1-us-west.apache.org [10.40.0.7]) (amavisd-new, port 10024) with ESMTP id fLCka9Ed4SWe for ; Fri, 4 Aug 2017 20:14:02 +0000 (UTC) Received: from mailrelay1-us-west.apache.org (mailrelay1-us-west.apache.org [209.188.14.139]) by mx1-lw-us.apache.org (ASF Mail Server at mx1-lw-us.apache.org) with ESMTP id BB6F05FD41 for ; Fri, 4 Aug 2017 20:14:01 +0000 (UTC) Received: from jira-lw-us.apache.org (unknown [207.244.88.139]) by mailrelay1-us-west.apache.org (ASF Mail Server at mailrelay1-us-west.apache.org) with ESMTP id 25C9EE0D45 for ; Fri, 4 Aug 2017 20:14:01 +0000 (UTC) Received: from jira-lw-us.apache.org (localhost [127.0.0.1]) by jira-lw-us.apache.org (ASF Mail Server at jira-lw-us.apache.org) with ESMTP id 8540E24654 for ; Fri, 4 Aug 2017 20:14:00 +0000 (UTC) Date: Fri, 4 Aug 2017 20:14:00 +0000 (UTC) From: "Svetlin Zarev (JIRA)" To: commits@openejb.apache.org Message-ID: In-Reply-To: References: Subject: [jira] [Updated] (TOMEE-2108) TomEEContainer (arquillian) does not clean up after failed deployment. MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-JIRA-FingerPrint: 30527f35849b9dde25b450d4833f0394 archived-at: Fri, 04 Aug 2017 20:14:06 -0000 [ 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} {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} {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} > > > > > > > {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)