Mailing-List: contact tomcat-dev-help@jakarta.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Tomcat Developers List" <tomcat-dev@jakarta.apache.org>
Message-ID: <3EB6D08E.6020904@apache.org>
Date: Mon, 05 May 2003 22:58:54 +0200
From: Remy Maucherat <remm@apache.org>
Organization: ASF
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US;
 rv:1.3) Gecko/20030312
MIME-Version: 1.0
To: Tomcat Developers List <tomcat-dev@jakarta.apache.org>
Subject: [5.0] New deployer proposal
References: <20030505200131.12262.qmail@nagoya.betaversion.org>
In-Reply-To: <20030505200131.12262.qmail@nagoya.betaversion.org>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit

Hi,

I think the deployer from TC 4.1.x is lacking some important features, 
and is not convinient enough for use in development, or within an 
enterprise context.

To improve it, I think the expected behavior has to be clearly 
documented, because incremental hacks would only make things worse 
(although some improvements were made by Glenn's round of refactorings). 
So we have to agree on some documentation first, and then implement it.

Here's the outline of what I would propose (this lists only changes over 
the current deployer):

A) Auto deployer

- It would consider the following resource paths as related for 
deployment purposes: /foo, /foo.war, /foo.xml. That means that you can 
refer to one either the war or the expanded directory in server.xml.
- The deployer will attempt to remove Context declarations from 
server.xml (already done), as this is less manageable.
- If a WAR is newer than the associated expanded directory, the webapp 
will be redeployed.
- New properties: deployOnStartup (replaces autoDeploy), and autoDeploy 
(replaces liveDeploy); the current ones are confising.
- In autoDeploy mode, the web.xml, JAR files will be monitored for 
updates. If newer, the app will be stopped/started. If startup fails 
because the update was in progress, the process will be repeated.
- When deploying, JARs will be lazy copied always to the work directory, 
to avoid preventing updates to the deployed running application.

B) Manager (un)deploy

- install and remove will be removed.
- Remove webapp when undeploy. Also remove work directory (unless an 
option is specified), and context declaration file.
- Pause the host autoDeploy when doing any management operation on the host.
- Add a parameter to specify that an update will be forced on an 
existing webapp (ie, if one is already deployed on the same path, it 
will be undeployed before deploying the new webapp). In that mode, 
keeping the work directory will be the default behavior, to allow 
maintaining session state during the update.
- As an option on the host, the current requests being sent for a webapp 
being updated or reloaded will be idled until either the updating is 
complete or they timeout.
- (Optional) Versioning feature on deployed webapps ?
- For consistency, WARs, Context XML declarations, and expanded 
directories should be created in the host appBase, unless specified 
otherwise (parameter to be defined).
- UnpackWARs shoudl have the same effect as when a webapp is deployed by 
the host auto deployer.

The purpose of the new deployer is to be better for enterprise 
deployments (no, or fewer lost requests when updating webapps) and 
development environments (smarter auto updating and easier deployment 
scripts).

Comments ?

Remy


---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org