tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Costin Manolache <>
Subject Re: [5.0] New deployer proposal
Date Tue, 06 May 2003 03:09:38 GMT
Remy Maucherat wrote:

> 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.

I assume you are reffering to changes in tocmat5, not in the 4.1 tree ?

> 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.

I would use the oportunity to move foo.xml.
IMO it's a dangerous option, since a user would be able to place 
"priviledged" attributes. I think it foo.xml should be placed 
in conf/webapps ( for example ) - so user permissions can be used
( give regular users permissions in /webapps, but not in conf ).

Also - I would add a mechanism to support vhosts, like a 2-layer dir
structure ( VHOST/APP ).

> - The deployer will attempt to remove Context declarations from
> server.xml (already done), as this is less manageable.

+1 ( not sure what you mean by "attempt to remove" - we should 
remove them in the std distro and add a warning if they are found,
then remove them in next release )

> - 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.

+1 Maybe a "deployOnDemand" ( i.e. keep it undeployed until the first
request for the context is received - very nice if you have 100s of
infrequently used apps )

> - 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.

-0 - I would keep monitoring just web.xml...

> - When deploying, JARs will be lazy copied always to the work directory,
> to avoid preventing updates to the deployed running application.

On OSes that have this problem. Please let the option in for linux and 
others how don't.

> 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.

Not sure I understand. When will this happen ?

> - 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 ?

Not easy...

> - 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.

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message