Mailing-List: contact tomcat-dev-help@jakarta.apache.org; run by ezmlm
Message-ID: <3A9FEE31.66A27F03@eng.sun.com>
Date: Fri, 02 Mar 2001 11:02:09 -0800
From: "Craig R. McClanahan" <Craig.McClanahan@eng.sun.com>
MIME-Version: 1.0
To: tomcat-dev@jakarta.apache.org
Subject: Re: Tomcat 4 unpacking of WAR files behavior
References: <3A9E6047.EF163B03@voyager.apg.more.net>
 <00b601c0a289$66070810$82deb018@intalio.com>
 <3A9EBBE9.476C160C@voyager.apg.more.net>
 <011101c0a296$ccf6bbd0$82deb018@intalio.com>
 <3A9EC46D.8F037022@voyager.apg.more.net>
 <016001c0a29c$11b64650$82deb018@intalio.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Remy Maucherat wrote:

> > Remy,
> >
> > What I am trying to do is start a discussion of _what_ the behaviour
> should be,
> > so it can be fixed. I already consider the current behaviour to be broken.
>
> I'm mixed on the subject. Craig implemented it that way, so I want to hear
> his opinion on the subject.
>

The original rationale for the current behavior was/is a very common
user error
with Tomcat 3.x -- it goes like this:
* User drops a WAR file into "webapps" and restarts Tomcat
* Tomcat auto-expands the WAR and runs fine
* User updates the app, drops in an updated WAR, and restarts Tomcat
* Tomcat sees the expanded directory, and does NOT auto-expand
* User files a bug report "Tomcat does not reload my updated classes"
:-(

I'm open to suggestion for different behavior, but keep this scenario in
mind.

>
> > For example deploying a war on starutp, then undeploying it on shutdown
> > adds unnecessary overhead to the tomcat start/stop processing.  This would
> > be a huge issue in a hosting environment where you might have 100's of war
> > files.
>
> Yes sure. I think the best would be not to unpack the WARs (it's a lot
> cleaner).
>

+1, as long as we can keep performance reasonable.

>
> Remy
>

Craig