You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tomcat.apache.org by Remy Maucherat <re...@apache.org> on 2003/05/05 22:58:54 UTC
[5.0] New deployer proposal
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
Re: [5.0] New deployer proposal
Posted by Radim Kubacki <ra...@sun.com>.
Remy Maucherat wrote:
> Radim Kubacki wrote:
>
>> Remy,
>>
>> I am interested in your suggested changes and would like to hear more
>> about your plans. It seems to me that if you remove 'install' and will
>> keep only deploy utilizing PUT method the following flow can be affected
>>
>> build an app -> install?war=my_app_dir -> edit -> build -> reload
>
>
> You mean: edit the running webapp, and have it be reloaded automatically ?
> That's not going to change.
>
No, you initialy wrote that you're going to remove install and remove. I
asked whether deployment from local path will be dropped without
replacement or not. The actual change seems to be that functionality of
install and deploy will be merged into deploy command which is good. The
result is simpler and with added update and tag attributes more powerfull.
>>>> - 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.
>>>
>>>
>>>
>>>
>>> Sounds good and can help tools.
>>>
>> Does it mean that if you do 'deploy?update=true' and send only changed
>> content it will work? Kind of incremental deployment?
>
>
> Yes. Well, I hope it will work, at least ;-)
>
It sounds interesting.
thanks,
Radim
> I started to update the docs according to the proposed behavior.
>
> Remy
---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
Re: [5.0] New deployer proposal
Posted by Remy Maucherat <re...@apache.org>.
Radim Kubacki wrote:
> Remy,
>
> I am interested in your suggested changes and would like to hear more
> about your plans. It seems to me that if you remove 'install' and will
> keep only deploy utilizing PUT method the following flow can be affected
>
> build an app -> install?war=my_app_dir -> edit -> build -> reload
You mean: edit the running webapp, and have it be reloaded automatically ?
That's not going to change.
>>> - 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.
>>
>>
>>
>> Sounds good and can help tools.
>>
> Does it mean that if you do 'deploy?update=true' and send only changed
> content it will work? Kind of incremental deployment?
Yes. Well, I hope it will work, at least ;-)
I started to update the docs according to the proposed behavior.
Remy
---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
Re: [5.0] New deployer proposal
Posted by Radim Kubacki <ra...@sun.com>.
Radim Kubacki wrote:
> 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):
>>
>> ...
>> B) Manager (un)deploy
>>
>> - install and remove will be removed.
>
>
> If you remove 'install' do you plan to enhance deploy with possibility
> to handle GET requests like 'deploy?war=foo.war'?
>
Remy,
I am interested in your suggested changes and would like to hear more
about your plans. It seems to me that if you remove 'install' and will
keep only deploy utilizing PUT method the following flow can be affected
build an app -> install?war=my_app_dir -> edit -> build -> reload
Also what about option start/not to start deployed application? This can
bring you closer to JSR88 deployment with distribute and start requests.
>> - 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.
>
>
> Sounds good and can help tools.
>
Does it mean that if you do 'deploy?update=true' and send only changed
content it will work? Kind of incremental deployment?
Radim
>
>> - 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
Re: [5.0] New deployer proposal
Posted by Radim Kubacki <ra...@sun.com>.
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):
>
> ...
> B) Manager (un)deploy
>
> - install and remove will be removed.
If you remove 'install' do you plan to enhance deploy with possibility
to handle GET requests like 'deploy?war=foo.war'?
> - 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.
Sounds good and can help tools.
Radim
> - 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
>
---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
Re: [5.0] New deployer proposal
Posted by Jonas Anden <jo...@aptilo.com>.
> A) Auto deployer
...
> - New properties: deployOnStartup (replaces autoDeploy), and autoDeploy
> (replaces liveDeploy); the current ones are confising.
I'm not too happy about renaming the 'liveDeploy' property to
'autoDeploy'. Please use another name for that property.
Not that 'autoDeploy' doesn't fit, but rather because there is an (old)
property with that name already. While this may be fine for new
installations done by new admins, but I think admins will be even more
confused when a setting suddenly means something different...
// J
---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
Re: [5.0] New deployer proposal
Posted by Petr Jiricka <pe...@sun.com>.
Remy Maucherat wrote:
> Petr Jiricka wrote:
>
>>
>> Remy Maucherat wrote:
>>
>>> Hi,
>>>
>>
>>
>> [snip]
>>
>>
>>> - When deploying, JARs will be lazy copied always to the work
>>> directory, to avoid preventing updates to the deployed running
>>> application.
>>
>>
>>
>>
>> Does this mean that
>> servletContext.getResource("WEB-INF/lib/mytaglib.jar") will return a
>> URL pointing to the copy ?
>
>
> No. This is a resource access, not a CL access.
>
Well, I am afraid that this may prevent a successful reloading of the
application in some cases. For example, Jasper uses code similar to the
following:
String resourcePath = "/WEB-INF/lib/mytaglib.jar";
URL url = ctxt.getResource(resourcePath);
URL jarURL = new URL("jar:" + url.toString() + "!/");
URLConnection conn = (JarURLConnection) jarURL.openConnection();
....
If the URL obtained from the ServletContext points to the original jar
file, will not the jar file be locked on Windows ?
Petr
> I'll take into account everyone's suggestions and update the howtos
> (which actually pretty much mirror a typical Tomcat book chapters; I
> think we should "rebrand" the user HOWTOs as a book for TC users and
> admins ;-) ), and then we'll do another round of reviews.
>
> Remy
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
Re: [5.0] New deployer proposal
Posted by Remy Maucherat <re...@apache.org>.
Petr Jiricka wrote:
>
> Remy Maucherat wrote:
>
>> Hi,
>>
>
>
> [snip]
>
>
>> - When deploying, JARs will be lazy copied always to the work
>> directory, to avoid preventing updates to the deployed running
>> application.
>
>
>
> Does this mean that
> servletContext.getResource("WEB-INF/lib/mytaglib.jar") will return a URL
> pointing to the copy ?
No. This is a resource access, not a CL access.
I'll take into account everyone's suggestions and update the howtos
(which actually pretty much mirror a typical Tomcat book chapters; I
think we should "rebrand" the user HOWTOs as a book for TC users and
admins ;-) ), and then we'll do another round of reviews.
Remy
---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
Re: [5.0] New deployer proposal
Posted by Petr Jiricka <pe...@sun.com>.
Remy Maucherat wrote:
> Hi,
>
[snip]
> - When deploying, JARs will be lazy copied always to the work directory,
> to avoid preventing updates to the deployed running application.
Does this mean that
servletContext.getResource("WEB-INF/lib/mytaglib.jar") will return a URL
pointing to the copy ?
Thanks
Petr
>
> Remy
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
Re: [5.0] New deployer proposal
Posted by Glenn Nielsen <gl...@mail.more.net>.
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
Re: [5.0] New deployer proposal
Posted by Glenn Nielsen <gl...@mail.more.net>.
Costin Manolache wrote:
> 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 ).
>
I agree about the security concerns. My two big concerns are the
privileged attribute and the ability to set a docBase anywhere on
the server.
> 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 )
>
I agree, this will also make the admin app better. One of the
things I dislike about the admin app is the rewriting of server.xml
for deployed applications. Moving to separate {context}.xml files
will help this work better.
>
>>- If a WAR is newer than the associated expanded directory, the webapp
>>will be redeployed.
>
>
> +1
>
>
>>- 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.
>
>
> +1
>
>
>>- 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.
>
>
> +1
>
>
>>- 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.
>
>
> +1
>
>
>>- (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).
>
>
> +1
>
>
>>- UnpackWARs shoudl have the same effect as when a webapp is deployed by
>>the host auto deployer.
>
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
Re: [5.0] New deployer proposal
Posted by Costin Manolache <cm...@yahoo.com>.
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.
+1
> - 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.
+1
> - 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.
+1
> - 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.
+1
> - (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).
+1
> - UnpackWARs shoudl have the same effect as when a webapp is deployed by
> the host auto deployer.
---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org