tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Christopher Schultz <ch...@christopherschultz.net>
Subject Re: Automatic deployment changes
Date Tue, 14 May 2013 19:55:06 GMT
Mark,

On 5/13/13 3:35 AM, Mark Thomas wrote:
> On 08/05/2013 15:18, Christopher Schultz wrote:
> 
>> Perhaps I should clarify my question with an example: what happens
>> when a WAR file is found and a DIR also exists with the same
>> context name, but expandWars is false? Does the directory get
>> updated with the contents of the WAR file, or does the WAR's
>> descriptor control the deployment (subject to all the other
>> behavior covered by your table(s)) and then (potentially old)
>> content is served from the pre-existing DIR?
> 
> Ah. One of the edge cases that makes this rather more complex than it
> first appears.
> 
> There are a couple of ways to get Tomcat into this state. They ways I
> can think of are:
> a) deploy the WAR then copy the DIR
> b) deploy the DIR, stop Tomcat, copy the WAR, start Tomcat
> 
> There may be others.
> 
> Note for case b) if Tomcat is running, the DIR will be removed.
> 
> In both cases what should happen is that the content is served from
> the WAR and the DIR is ignored. The question is what happens when the
> WAR is removed? Is the DIR removed as well? Alternatively, should the
> DIR be removed as soon as it is detected?
> 
> I'm leaning towards the DIR just being ignored but a warning logged.
> That would mean:
> - Content is served from the WAR
> - The DIR remains but is unused
> - A warning will be logged when the DIR is first detected
> - If the WAR is removed, the DIR will be deployed
> 
> There are similar questions about what happens if you have XML +
> WAR(external) + DIR (expanded) and you add a WAR to the appBase?
> Again, I'm leaning towards ignoring it apart from a warning when it is
> first detected.
> 
> 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?

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.

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.

-chris


Mime
View raw message