tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Remy Maucherat" <>
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".
> 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

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
> exists
>   -> The previous war file components are removed, then the war file
>      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
> 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
>      how would you determine that the war file is not a replacement.
>      An updated war file was installed and the directory is for the
>      expanded version.  What if the web app saves configuration info to
>      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
>    servlet to redploy a web app.



View raw message