tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Glenn Nielsen <>
Subject Re: Tomcat 4.1-dev Host unpackWARs not working
Date Thu, 28 Feb 2002 20:25:24 GMT
"Craig R. McClanahan" wrote:
> On Thu, 28 Feb 2002, Glenn Nielsen wrote:
> > Date: Thu, 28 Feb 2002 10:57:55 -0600
> > From: Glenn Nielsen <>
> > Reply-To: Tomcat Developers List <>
> > To: Tomcat Developers List <>
> > Subject: Re: Tomcat 4.1-dev Host unpackWARs not working
> >
> > "Craig R. McClanahan" wrote:
> > >
> > > On Thu, 28 Feb 2002, Glenn Nielsen wrote:
> > >
> > > > Date: Thu, 28 Feb 2002 09:18:39 -0600
> > > > From: Glenn Nielsen <>
> > > > Reply-To: Tomcat Developers List <>
> > > > To:
> > > > Subject: Tomcat 4.1-dev Host unpackWARs not working
> > > >
> > > > The Host attribute unpackWARs="true" is not working in the Tomcat 4 HEAD
> > > > version.
> > > >
> > > > I think it is due to the following at line 232 in
> > > > If you turn debug on you will see that a war file in the webapps directory
> > > > is deployed using a jar:file URL.
> > > >
> > > >         // Expand a WAR archive into an unpacked directory if needed
> > > >         // NOTE:  If the user supplies a "jar:file:" URL, assume that
> > > >         // they do not want WAR expansion even if unpackWARs is set
> > > >         if (host.isUnpackWARs() && !url.startsWith("jar:file:"))
> > > >
> > > > What is the reason for making the above assumption?
> > > >
> > > > If there is a valid reason for doing this, it should be documented
> > > > that unpackWARs="true" works except when ...
> > > >
> > >
> > > This comment is embedded inside the install() method, which accepts a URL
> > > to either a WAR or a directory.  Since the person doing the deployment
> > > (typically using the manager webapp) consciously made a choice to send one
> > > or the other, it's not a good idea for the container to second guess that
> > > choice.
> > >
> >
> > I don't think that is a valid assumption.  It may have just been easier for
> > the user to install a war file in their hosts webapp directory than install
> > the unpacked files.
> >
> For things inside the appBase directory (i.e. $CATALINA_HOME/webapps by
> default), I don't see huge problems with unpacking.  However, if I install
> a WAR file with an absolute path that is outside this directory, like
> this:
>   http://localhost:8080/manager/install?path=/foo&war=jar:file:/home/craigmcc/mywar.war!/
> then there are not very many good options for where to unpack to.  (I
> certainly don't want Tomcat creating a directory in my home directory.)

Simple, if unpackWARs is true, the war file and the unpacked version of it
get installed in the hosts appBase.  Renaming the war as needed to match the
context path.

> And, what does it mean to dynamically remove an application that has been
> deployed this way?  We currently don't delete the auto-unpacked directory,
> and neither do we re-unpack on top of it.

Remove or undeploy should do what they say, remove everything related to
that application whether it exists in the hosts appBase or in the workDir.

> IMHO, auto-unpack is a hack we have to keep around for legacy backwards
> compatibility.  People doing dynamic install or deploy should choose what
> they want to do, and then send that argument (either a directory or a WAR
> file).  Auto-unpack should be explicitly defined to work only in the
> appBase directory.  Dynamic installation should install exactly what the
> user said to install, and not mess around with it.

I don't think auto-unpack is necessarily a hack.  There are valid reasons for
someone to want to have an unpacked version of a war.  For example, if the app
uses JSP pages, they may just want to update a single JSP page in the unpacked app.
They can update the application this way without even doing a reload.

Behaviour needs to be clear and consistent for managing webapps.

Quite a while ago when I did some work on the manager I wrote up and
posted a document on the expected behaviour of Tomcat in each situation.

Perhaps that needs to be updated or recreated so we can look at the whole picture.

Here is what I posted 3/13/01, this is just a starting point to flush out
what the expected behaviour of Tomcat and the manager serlvet is for
managing webapps.


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 

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




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

To unsubscribe, e-mail:   <>
For additional commands, e-mail: <>

View raw message