tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mark Thomas <>
Subject Re: Automatic deployment changes
Date Wed, 15 May 2013 11:38:33 GMT
On 14/05/2013 20:55, Christopher Schultz wrote:
> On 5/13/13 3:35 AM, Mark Thomas wrote:

>> I've updated the proposal to cover these.
> Cool. Having all the rules in one place will be tremendously helpful to
> users. Even if they disagree with the rules, they will at least be
> predictable without having to read the code.


> IIRC, it used to be that Tomcat would unconditionally expand the WAR
> file "for performance reasons". Are those performance reasons no longer
> considered warranted, or has "expandWars" been added so that deployers
> who don't want anything written to the disk can have their way?

unpackWARs has been present for as long as I can remember. Certainly
from Tomcat 4 onwards the intention was that a web app could be a WAR, a
directory or served from anywhere such as a database.

> I'm wondering if a somewhat reasonable change might be to deploy the
> "true" webapp into the work/ directory to resolve these conflicts. So,
> for instance, deploying a WAR file would result in the expansion of the
> WAR file into the work/ directory instead of into webapps/, while
> deployment of a DIR would copy to work/ and serve from there. That way,
> you don't have to worry about potentially killing a DIR when a WAR needs
> to be deployed.

I think that just changes the problem because a user could copy an app
directory and app.war into webapps.

> Of course, that could cause (further?) confusion between the behavior of
> WAR, DIR, and work-DIR for users trying to track-down some obscure
> change they (think they) made and why they can't get it to show up in
> their webapp.

Indeed. We see this when the various anti-resource locking options are used.

I think keeping the process as simple as possible is the way forward,
both for user understanding and simplicity of code.


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

View raw message