tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Remy Maucherat" <r...@apache.org>
Subject Re: [PROPOSAL] Tomcat 4 unpacking of WAR files behavior
Date Sat, 03 Mar 2001 23:22:56 GMT
> "Craig R. McClanahan" wrote:
> >
> > Remy Maucherat wrote:

> > 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.
> >
>
> That "problem" is taken care of if the user configures the Context with
> unpackWARs="false", and can be documented in the user config docs.
>
> The current behaviour could lead to other bug reports, "I changed some
> files in an expanded WAR file, but when I restarted Tomcat my changes
> are missing".
>
> [PROPOSAL]
>
> Tomcat Startup
> **************
>
> If unpackWARs="false"
> ---------------------
>
> If a new war file exists with no corresponding expanded war file
>
>   -> The war file componenets are expanded out as needed into the work
dir.

Until Jasper is fixed (if it is ever fixed). It is possible to know whether
or not a context uses Jasper, so this operation could be smarter.

> If a  war file with a last mod time newer than the unpacked war file
components
> exists
>
>   -> The previous war file components are removed, then the war file
components
>      are expanded as needed into work dir.

That looks a bit too risky ...
I wouldn't remove anything in that case just to be safe.

> If unpackWARs="true"
> --------------------
>
> A war file exits, but no directory exists matching war file prefix.
>
>   -> create directory name matching war file prefix and expand war file.
>
> A war file exists, and a corresponding directory exists.  The war file
last
> mod time is older than directory.
>
>   -> Don't expand war file.
>
> A war file exists, and a corresponding directory exists. The war file last
> mod time is newer than the directory.
>
>    You have one of two cases:
>
>      A completely different web app exists in a directory with the same
name as
>      a new war file.  You wouldn't want Tomcat to overwrite another web
app,
>      how would you determine that the war file is not a replacement.
>
>      An updated war file was installed and the directory is for the
previously
>      expanded version.  What if the web app saves configuration info to
property
>      files in /WEB-INF/classes, or other data in /WEB-INF?
>
>    In both cases I think you should not do anything, just log an
information message
>    to the Context log.  Let the user decide, perhaps they could use the
manager
>    servlet to redploy a web app.

+1.

Remy


Mime
View raw message