Return-Path: Delivered-To: apmail-geronimo-dev-archive@www.apache.org Received: (qmail 56780 invoked from network); 23 Jul 2005 16:07:11 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (209.237.227.199) by minotaur.apache.org with SMTP; 23 Jul 2005 16:07:11 -0000 Received: (qmail 53529 invoked by uid 500); 23 Jul 2005 16:07:04 -0000 Delivered-To: apmail-geronimo-dev-archive@geronimo.apache.org Received: (qmail 53429 invoked by uid 500); 23 Jul 2005 16:07:03 -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 53348 invoked by uid 99); 23 Jul 2005 16:07:02 -0000 X-ASF-Spam-Status: No, hits=0.0 required=10.0 tests=SPF_FAIL X-Spam-Check-By: apache.org Received: from [192.87.106.226] (HELO ajax.apache.org) (192.87.106.226) by apache.org (qpsmtpd/0.29) with ESMTP; Sat, 23 Jul 2005 09:06:50 -0700 Received: from ajax.apache.org (ajax.apache.org [127.0.0.1]) by ajax.apache.org (Postfix) with ESMTP id 9A210DA for ; Sat, 23 Jul 2005 18:06:46 +0200 (CEST) Message-ID: <759078685.1122134806630.JavaMail.jira@ajax.apache.org> Date: Sat, 23 Jul 2005 18:06:46 +0200 (CEST) From: "Aaron Mulder (JIRA)" To: dev@geronimo.apache.org Subject: [jira] Created: (GERONIMO-803) Deploy failure during redeploy leaves app undeployed Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Virus-Checked: Checked by ClamAV on apache.org X-Spam-Rating: minotaur.apache.org 1.6.2 0/1000/N Deploy failure during redeploy leaves app undeployed ---------------------------------------------------- Key: GERONIMO-803 URL: http://issues.apache.org/jira/browse/GERONIMO-803 Project: Geronimo Type: Bug Components: deployment Versions: 1.0-M3 Reporter: Aaron Mulder Fix For: 1.0 Ouch, this is a nasty one. If you deploy app Foo, then change it to be broken (invalid DD, whatever) and redeploy it, it goes like this: 1) undeploy old one 2) try to deploy new one 3) fail The result is that the old one has been undeployed but the new one hasn't been deployed. It would be ideal if we could "try" the deploy operation first, and only if it appears valid, undeploy the old version and start the new version. I'm not sure how that could be done. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira