[PROPOSAL] Tomcat 4 unpacking of WAR files behavior

[Glenn Nielsen <gl...@voyager.apg.more.net>]

"Craig R. McClanahan" wrote:
> 
> 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.
> 

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.

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.


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.
   

Tomcat Shutdown
***************

When tomcat is shutdown it should not remove any unpacked war files, whether
unpackWARs is true or false.

Tomcat Runtime
**************

In a web hosting environment I envision the manager servlet getting used a
great deal by users to manage their web apps. The manager would most likely
be invoked by some web app administration tool which does authentication and
authorization.  The DefaultContext would set unpackWARs="true", since that
is the default behaviour for a Context deployed using the manager.

The manager servlet currently supports the following:

list - List the context paths of all web applications currently deployed on 
      the virtual host in which this manager application is deployed.
 
deploy?path=/xxx&war=yyy - Deploy the web application whose WAR file (or directory
      containing the unpacked application) is present at URL yyy, and attach it to 
      context path /xxx. See below for valid syntax options for the web applcation 
      archive URl. If the URL of an actual WAR file is specified, the WAR will be 
      automatically expanded into a directory underneath the application base for 
      this virtual host. 

      [PROPOSAL] Change the command name to "install".  If the web app already
      exists the install will fail.  The user will have to "remove" it first.
      The "war" file is renamed if necessary so its prefix is the same name as the path.

reload?path=/xxx - Cause the web application deployed at context path /xxx to reload 
      all its associated Java classes, even if automatic reloading is disabled.
 
undeploy?path=/xxx - Cause the web application deployed at context path /xxx to be 
      gracefully shut down and undeployed. If a WAR file was automatically expanded 
      into an unpacked directory when this application was deployed (or when the 
       servlet container was first started), the expanded directory is deleted.

      [PROPOSAL] Change the command name to "stop".  Do not remove the expanded 
       web app directory when undeployed.  Perhaps the user just wants to stop 
       the web app for maintenance reasons, and will start the web app again after 
       the maintenance is over.

[PROPOSAL] New manager servlet commands

remove?path=/xxx - Undeploy and remove the web application from the server.
       This removes the expanded war file directory and the war file.

start?path=/xxx - Start a web app that is installed but not running.

update?path=/xxx&war=yyy - Update a web application with a new war file.
       The web app is stopped.  Only those unmodified files expanded from 
       the original war file are removed, then the war file is expanded,
       and the Context restarted.

The new list of manager servlet commands would be:

install
update
start
reload
list
stop
remove

Regards,

Glenn

----------------------------------------------------------------------
Glenn Nielsen             glenn@more.net | /* Spelin donut madder    |
MOREnet System Programming               |  * if iz ina coment.      |
Missouri Research and Education Network  |  */                       |
----------------------------------------------------------------------

Re: [PROPOSAL] Tomcat 4 unpacking of WAR files behavior

[Remy Maucherat <re...@apache.org>]

> "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