Mailing-List: contact dev-help@geronimo.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@geronimo.apache.org
Date: Fri, 22 Jul 2011 09:45:57 +0000 (UTC)
From: "Rex Wang (JIRA)" <jira@apache.org>
To: dev@geronimo.apache.org
Message-ID: 
 <1745606603.14160.1311327957729.JavaMail.tomcat@hel.zones.apache.org>
In-Reply-To: 
 <309603829.13806.1311314817668.JavaMail.tomcat@hel.zones.apache.org>
Subject: [jira] [Commented] (GERONIMO-6093) Hot-deploy scenarios
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit


    [ https://issues.apache.org/jira/browse/GERONIMO-6093?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13069467#comment-13069467 ] 

Rex Wang commented on GERONIMO-6093:
------------------------------------

>From GERONIMO-5994, the non-deployed file will not delete autoly from hot deploy folder, so logic might be a little complicated. I tried simplify the codes at revision: 1149529 to satisfy the above scenarios.

-Rex

> Hot-deploy scenarios
> --------------------
>
>                 Key: GERONIMO-6093
>                 URL: https://issues.apache.org/jira/browse/GERONIMO-6093
>             Project: Geronimo
>          Issue Type: Bug
>      Security Level: public(Regular issues) 
>    Affects Versions: 3.0
>            Reporter: Rex Wang
>            Assignee: Rex Wang
>             Fix For: 3.0
>
>
> I create this jira to record some special Hot-deploy scenarios so that we won't bring some regressions after modifying the hot-deployer codes. 
> 1. hotdeploy and then undeploy from console.
> 1). hot-deploy A successfully
> 2). undeploy A from console, then the A should be deleted from hotdeploy folder
> 3). restart server, then nothing error/warn messages prompt. 
> ##PS, this tests the file can be deleted if the undeployment happened in other means, and the persist file records must be changed as well.
> 2. Add a re-named app along with the original one.
> 1). hot-deploy A successfully
> 2). put in A2, which made by renaming the A, then an warn message should prompt to tell "the module has been deployed", and A2 should not be deleted automatically.
> ##PS, this tests a new app, whose config id existed in server, will not be deployed
> 3. Delete a app that was not hot deployed successfully.
> 1). after the steps in #2
> 2). delete A2, then nothing error/warn messages prompt. 
> ##PS, this tests the deletion of a non-deployed file won't cause another module to be undeployed
> 4. Put in a modified app to replace the one has been successfully deployed before
> 1). hot-deploy A successfully
> 2). re-create A, which means its size or modification time will be changed, and replace the one in hot deploy folder, then A must be redeployed.
> 5. Put in a modified app to replace the one was not successfully deployed before
> 1). hot-deploy A successfully
> 2). put in A2, (defined in #2), then it will not be deployed because of the same config ID.
> 3). re-create A2, and replace the one in hot deploy folder, then A2 must not be redeployed (Otherwise it will firstly undeploy the module deployed by A)

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira