Return-Path: Delivered-To: apmail-geronimo-dev-archive@www.apache.org Received: (qmail 73617 invoked from network); 14 Aug 2009 21:59:33 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.3) by minotaur.apache.org with SMTP; 14 Aug 2009 21:59:33 -0000 Received: (qmail 12738 invoked by uid 500); 14 Aug 2009 21:59:39 -0000 Delivered-To: apmail-geronimo-dev-archive@geronimo.apache.org Received: (qmail 12616 invoked by uid 500); 14 Aug 2009 21:59:39 -0000 Mailing-List: contact dev-help@geronimo.apache.org; run by ezmlm Precedence: bulk list-help: list-unsubscribe: List-Post: Reply-To: dev@geronimo.apache.org List-Id: Delivered-To: mailing list dev@geronimo.apache.org Received: (qmail 12599 invoked by uid 99); 14 Aug 2009 21:59:39 -0000 Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230) by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 14 Aug 2009 21:59:39 +0000 X-ASF-Spam-Status: No, hits=-2000.0 required=10.0 tests=ALL_TRUSTED X-Spam-Check-By: apache.org Received: from [140.211.11.140] (HELO brutus.apache.org) (140.211.11.140) by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 14 Aug 2009 21:59:36 +0000 Received: from brutus (localhost [127.0.0.1]) by brutus.apache.org (Postfix) with ESMTP id D353E234C045 for ; Fri, 14 Aug 2009 14:59:14 -0700 (PDT) Message-ID: <1199707141.1250287154864.JavaMail.jira@brutus> Date: Fri, 14 Aug 2009 14:59:14 -0700 (PDT) From: "Kevan Miller (JIRA)" To: dev@geronimo.apache.org Subject: [jira] Commented: (GERONIMO-4795) Multiple Server Instances: Uninstalling an application does not remove the entry from config.xml of other server instances In-Reply-To: <563697914.1250239154881.JavaMail.jira@brutus> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-JIRA-FingerPrint: 30527f35849b9dde25b450d4833f0394 X-Virus-Checked: Checked by ClamAV on apache.org [ https://issues.apache.org/jira/browse/GERONIMO-4795?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12743464#action_12743464 ] Kevan Miller commented on GERONIMO-4795: ---------------------------------------- That may be how you *think* the server should be used. Although I think a "disposable" server model for using Geronimo is an excellent technique, it's not the only technique. I certainly talk with users who have decided not to manage their Geronimo environment in this way... So, I'm not so quick to dismiss this basic scenario... That said, I think I agree that we should *not* support this undeploy behavior... Seems like there are 3 potential ways to end up in the state described by Ashish: 1) deploy an app/plugin to the default server, then copy var/* to a new server instance 2) deploy a plugin to any server (using the default repository), then deploy the plugin only using a deployment plan (I'm only guessing that this might work). 3) deploy an app/plugin, then manually copy the config.xml changes into the other server's config.xml I don't think these "deploy" techniques imply that we'll automatically "undeploy" the apps. User management was required, when deploying the apps to the multiple servers. User Management will be required, when undeploying. Personally, I think the best technique for handling this scenario is with server specific repositories on each server instance. If you want to run the same app on all server instances, you should explicitly deploy/undeploy to each server instance. > Multiple Server Instances: Uninstalling an application does not remove the entry from config.xml of other server instances > -------------------------------------------------------------------------------------------------------------------------- > > Key: GERONIMO-4795 > URL: https://issues.apache.org/jira/browse/GERONIMO-4795 > Project: Geronimo > Issue Type: Bug > Security Level: public(Regular issues) > Components: commands > Affects Versions: 2.1.3, 2.1.4 > Environment: Windows XP G 214 > Reporter: Ashish Jain > Assignee: Ashish Jain > Fix For: 2.2 > > > 1) Setup another geronimo instance out of the same installation directory. > 2) Deploy an applicaton to one instance. This will result in entry being created in config.xml for both the instances > 3) Undeploy the application. This results in entry being removed from config.xml of one instance and other instance > still has entry of the application in config.xml. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.