tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Glenn Nielsen <gl...@mail.more.net>
Subject Re: [5.0] New deployer proposal
Date Tue, 06 May 2003 12:43:11 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.
> 
> 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.

  Isn't this for deployOnStartup rather than autoDeploy?
  Would the order used to identify what resource to instantiate as
  a webapp be the order you listed above?

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

   This should be done during an undeploy rather than during a deploy.
   i.e. server.xml
> - If a WAR is newer than the associated expanded directory, the webapp 
> will be redeployed.

   This could be tricky.

> - New properties: deployOnStartup (replaces autoDeploy), and autoDeploy 
> (replaces liveDeploy); the current ones are confising.

   Sounds good.

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

How does this work with reloadable? Can this be disabled?  This could
be tricky.

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

I would like to see this broken out into three sections:

1. Actions taken to deploy applications on startup.

2. Actions taken to deploy applications at runtime.

3. Actions taken to deploy applications by the manager.

With the new Context config attributes being used in the docs.

> B) Manager (un)deploy
> 
> - install and remove will be removed.

  Fine as long as deploy/undeploy work similarly to the existing install/remove.
  It sounds like your proposal does this.

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

  Perhaps there should be an attribute to enable/disable this.
  It would be possible for 100's of requests to queue up during
  a start/stop of a web application.  When it then becomes available
  this can cause problems for Tomcat if it tries to handle 100's
  of requests for a newly deployed webapp simultaneously.

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

  Yes.

> - UnpackWARs shoudl have the same effect as when a webapp is deployed by 
> the host auto deployer.

  Yes, unpackWARs should always be honored.
> 
> 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 ?
> 

What about the manager reload?  It currently doesn't reload the web.xml,
users often have problems with this behaviour.

> Remy
> 

Regards,

Glenn


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


Mime
View raw message