You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tomcat.apache.org by Glenn Nielsen <gl...@voyager.apg.more.net> on 2001/03/01 15:44:23 UTC
Tomcat 4 unpacking of WAR files behavior
What is the expected behaviour of Tomcat 4 when starting/stopping
in regards to unpacking war files.
I noticed what to me seems like strange behaviour.
The Host is configured in server.xml with unpackWARs="true".
ls of webapps before starting tomcat, notice that some of the war
files are not expanded out.
$ ls -l webapps
total 1091
drwxr-xr-x 9 tomcatd tomcatd 512 Feb 18 09:06 ROOT
drwxr-xr-x 8 tomcatd tomcatd 512 Feb 18 09:06 examples
drwxr-xr-x 5 tomcatd tomcatd 512 Feb 17 06:42 jdbc-doc
-rw-r--r-- 1 tomcatd tomcatd 168332 Feb 15 16:19 jdbc-doc.war
drwxr-xr-x 4 tomcatd tomcatd 512 Feb 25 20:27 jdbc-examples
-rw-r--r-- 1 tomcatd tomcatd 39156 Feb 15 16:19 jdbc-examples.war
drwxr-xr-x 5 tomcatd tomcatd 512 Feb 16 13:20 jndi-doc
-rw-r--r-- 1 tomcatd tomcatd 79042 Feb 15 16:37 jndi-doc.war
drwxr-xr-x 4 tomcatd tomcatd 512 Feb 17 06:42 jndi-examples
-rw-r--r-- 1 tomcatd tomcatd 33516 Feb 15 16:37 jndi-examples.war
-rw-r--r-- 1 tomcatd tomcatd 411591 Mar 1 06:09 jsp-tests.war
drwxr-xr-x 5 tomcatd tomcatd 512 Feb 18 09:06 manager
drwxr-xr-x 5 tomcatd tomcatd 512 Feb 17 06:42 request-doc
-rw-r--r-- 1 tomcatd tomcatd 159409 Feb 16 13:25 request-doc.war
drwxr-xr-x 4 tomcatd tomcatd 512 Feb 17 06:42 request-examples
-rw-r--r-- 1 tomcatd tomcatd 36690 Feb 16 13:25 request-examples.war
-rw-r--r-- 1 tomcatd tomcatd 51150 Feb 26 20:36 scrape-doc.war
-rw-r--r-- 1 tomcatd tomcatd 86902 Feb 26 20:36 scrape-examples.war
drwxr-xr-x 5 tomcatd tomcatd 512 Feb 18 09:06 webdav
ls of webapps after starting tomcat, all war files are expanded.
$ ls -l webapps
total 1094
drwxr-xr-x 9 tomcatd tomcatd 512 Feb 18 09:06 ROOT
drwxr-xr-x 8 tomcatd tomcatd 512 Feb 18 09:06 examples
drwxr-xr-x 5 tomcatd tomcatd 512 Feb 17 06:42 jdbc-doc
-rw-r--r-- 1 tomcatd tomcatd 168332 Feb 15 16:19 jdbc-doc.war
drwxr-xr-x 4 tomcatd tomcatd 512 Feb 25 20:27 jdbc-examples
-rw-r--r-- 1 tomcatd tomcatd 39156 Feb 15 16:19 jdbc-examples.war
drwxr-xr-x 5 tomcatd tomcatd 512 Feb 16 13:20 jndi-doc
-rw-r--r-- 1 tomcatd tomcatd 79042 Feb 15 16:37 jndi-doc.war
drwxr-xr-x 4 tomcatd tomcatd 512 Feb 17 06:42 jndi-examples
-rw-r--r-- 1 tomcatd tomcatd 33516 Feb 15 16:37 jndi-examples.war
drwxr-xr-x 5 tomcatd tomcatd 512 Mar 1 08:27 jsp-tests
-rw-r--r-- 1 tomcatd tomcatd 411591 Mar 1 06:09 jsp-tests.war
drwxr-xr-x 5 tomcatd tomcatd 512 Feb 18 09:06 manager
drwxr-xr-x 5 tomcatd tomcatd 512 Feb 17 06:42 request-doc
-rw-r--r-- 1 tomcatd tomcatd 159409 Feb 16 13:25 request-doc.war
drwxr-xr-x 4 tomcatd tomcatd 512 Feb 17 06:42 request-examples
-rw-r--r-- 1 tomcatd tomcatd 36690 Feb 16 13:25 request-examples.war
drwxr-xr-x 5 tomcatd tomcatd 512 Mar 1 08:28 scrape-doc
-rw-r--r-- 1 tomcatd tomcatd 51150 Feb 26 20:36 scrape-doc.war
drwxr-xr-x 4 tomcatd tomcatd 512 Mar 1 08:28 scrape-examples
-rw-r--r-- 1 tomcatd tomcatd 86902 Feb 26 20:36 scrape-examples.war
drwxr-xr-x 5 tomcatd tomcatd 512 Feb 18 09:06 webdav
ls of webapps after stopping tomcat, notice that the war files that
tomcat had expanded out now have their directories removed.
$ ls -l webapps
total 1091
drwxr-xr-x 9 tomcatd tomcatd 512 Feb 18 09:06 ROOT
drwxr-xr-x 8 tomcatd tomcatd 512 Feb 18 09:06 examples
drwxr-xr-x 5 tomcatd tomcatd 512 Feb 17 06:42 jdbc-doc
-rw-r--r-- 1 tomcatd tomcatd 168332 Feb 15 16:19 jdbc-doc.war
drwxr-xr-x 4 tomcatd tomcatd 512 Feb 25 20:27 jdbc-examples
-rw-r--r-- 1 tomcatd tomcatd 39156 Feb 15 16:19 jdbc-examples.war
drwxr-xr-x 5 tomcatd tomcatd 512 Feb 16 13:20 jndi-doc
-rw-r--r-- 1 tomcatd tomcatd 79042 Feb 15 16:37 jndi-doc.war
drwxr-xr-x 4 tomcatd tomcatd 512 Feb 17 06:42 jndi-examples
-rw-r--r-- 1 tomcatd tomcatd 33516 Feb 15 16:37 jndi-examples.war
-rw-r--r-- 1 tomcatd tomcatd 411591 Mar 1 06:09 jsp-tests.war
drwxr-xr-x 5 tomcatd tomcatd 512 Feb 18 09:06 manager
drwxr-xr-x 5 tomcatd tomcatd 512 Feb 17 06:42 request-doc
-rw-r--r-- 1 tomcatd tomcatd 159409 Feb 16 13:25 request-doc.war
drwxr-xr-x 4 tomcatd tomcatd 512 Feb 17 06:42 request-examples
-rw-r--r-- 1 tomcatd tomcatd 36690 Feb 16 13:25 request-examples.war
-rw-r--r-- 1 tomcatd tomcatd 51150 Feb 26 20:36 scrape-doc.war
-rw-r--r-- 1 tomcatd tomcatd 86902 Feb 26 20:36 scrape-examples.war
drwxr-xr-x 5 tomcatd tomcatd 512 Feb 18 09:06 webdav
What is the point in having Tomcat 4 unpack the war files if it removes
the unpacked war file directory when Tomcat stops?
Why are some unpacked war file directories removed, and others are left alone?
What if you modified the web application you installed, or it manages some
properties files in its own WEB-INF/classes directory?
Is this the expected behaviour?
Regards,
Glenn
----------------------------------------------------------------------
Glenn Nielsen glenn@more.net | /* Spelin donut madder |
MOREnet System Programming | * if iz ina coment. |
Missouri Research and Education Network | */ |
----------------------------------------------------------------------
Re: Tomcat 4 unpacking of WAR files behavior
Posted by Remy Maucherat <re...@apache.org>.
> On Fri, 2 Mar 2001, Craig R. McClanahan wrote:
> > > 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.
>
> Well, memory's cheap. You can always just read the whole WAR in.
Performance should be good with WARs (ie, you shouldn't notice anything
really different). On startup, a table of contents of the WAR is built
(otherwise, browsing isn't possible).
> Then you'll get great performance. :)
> As a middle ground, it probably wouldn't be too horrible to
> implement a ClassLoader that cached frequently-accessed resources from
> the WAR.
The classloader loads stuff using URL connections pointing to the directory
context which then accesses the WAR. The caching is done at the directory
context layer.
There is no caching of the content yet. Only the metadata is cached right
now (but content caching can be added fairly easily (although I don't know
if it would be that useful, since the OS content caching is quite
efficient - I suggest adding that only if benchmark figures are too low).
Remy
Re: Tomcat 4 unpacking of WAR files behavior
Posted by Aaron Mulder <am...@alumni.princeton.edu>.
On Fri, 2 Mar 2001, Craig R. McClanahan wrote:
> > 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.
Well, memory's cheap. You can always just read the whole WAR in.
Then you'll get great performance. :)
As a middle ground, it probably wouldn't be too horrible to
implement a ClassLoader that cached frequently-accessed resources from
the WAR.
Aaron
Re: [PROPOSAL] Tomcat 4 unpacking of WAR files behavior
Posted by 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
[PROPOSAL] Tomcat 4 unpacking of WAR files behavior
Posted by 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: Tomcat 4 unpacking of WAR files behavior
Posted by "Craig R. McClanahan" <Cr...@eng.sun.com>.
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
Re: Tomcat 4 unpacking of WAR files behavior
Posted by Remy Maucherat <re...@apache.org>.
> 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.
> 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).
Remy
Re: Tomcat 4 unpacking of WAR files behavior
Posted by Glenn Nielsen <gl...@voyager.apg.more.net>.
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.
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.
Regards,
Glenn
Remy Maucherat wrote:
>
> > I consider this a bug. Tomcat should not be removing contexts that have
> > been expanded out into a directory in webapps.
> >
> >
> > If unpackWARs="false", then nothing is expanded out into webapss, the war
> > file is expanded out as needed into the work dir, correct?
>
> The JARs are indeed expanded as a temporary fix for Jasper. There is hope
> that we can perhaps use a tweaked version of javac which would load classes
> from a classloader (in which case no expanding is needed).
>
> > But if unpackWARs="true", what should the behaviour be in the following
> cases:
> >
> > 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.
>
> That's what is done right now, except that the deployed (read : expanded)
> WAR is undeployed when you shut down Catalina.
>
> > 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, or an updated war file for was installed and the directory
> > is for the previously expanded version. What now?
> >
> > And when tomcat is shutdown it should not remove any unpacked war files,
> > this can significantly increase the time it takes tomcat to
> startup/shutdown.
>
> It will only remove files if it did actually deploy the corresponding WAR.
>
> Remy
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
> For additional commands, email: tomcat-dev-help@jakarta.apache.org
--
----------------------------------------------------------------------
Glenn Nielsen glenn@more.net | /* Spelin donut madder |
MOREnet System Programming | * if iz ina coment. |
Missouri Research and Education Network | */ |
----------------------------------------------------------------------
Re: Tomcat 4 unpacking of WAR files behavior
Posted by Remy Maucherat <re...@apache.org>.
> I consider this a bug. Tomcat should not be removing contexts that have
> been expanded out into a directory in webapps.
>
>
> If unpackWARs="false", then nothing is expanded out into webapss, the war
> file is expanded out as needed into the work dir, correct?
The JARs are indeed expanded as a temporary fix for Jasper. There is hope
that we can perhaps use a tweaked version of javac which would load classes
from a classloader (in which case no expanding is needed).
> But if unpackWARs="true", what should the behaviour be in the following
cases:
>
> 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.
That's what is done right now, except that the deployed (read : expanded)
WAR is undeployed when you shut down Catalina.
> 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, or an updated war file for was installed and the directory
> is for the previously expanded version. What now?
>
> And when tomcat is shutdown it should not remove any unpacked war files,
> this can significantly increase the time it takes tomcat to
startup/shutdown.
It will only remove files if it did actually deploy the corresponding WAR.
Remy
Re: Tomcat 4 unpacking of WAR files behavior
Posted by Glenn Nielsen <gl...@voyager.apg.more.net>.
Remy Maucherat wrote:
>
> > What is the expected behaviour of Tomcat 4 when starting/stopping
> > in regards to unpacking war files.
> >
> > I noticed what to me seems like strange behaviour.
> >
> > The Host is configured in server.xml with unpackWARs="true".
> >
> > ls of webapps before starting tomcat, notice that some of the war
> > files are not expanded out.
> >
> > $ ls -l webapps
> > total 1091
> > drwxr-xr-x 9 tomcatd tomcatd 512 Feb 18 09:06 ROOT
> > drwxr-xr-x 8 tomcatd tomcatd 512 Feb 18 09:06 examples
> > drwxr-xr-x 5 tomcatd tomcatd 512 Feb 17 06:42 jdbc-doc
> > -rw-r--r-- 1 tomcatd tomcatd 168332 Feb 15 16:19 jdbc-doc.war
> > drwxr-xr-x 4 tomcatd tomcatd 512 Feb 25 20:27 jdbc-examples
> > -rw-r--r-- 1 tomcatd tomcatd 39156 Feb 15 16:19 jdbc-examples.war
> > drwxr-xr-x 5 tomcatd tomcatd 512 Feb 16 13:20 jndi-doc
> > -rw-r--r-- 1 tomcatd tomcatd 79042 Feb 15 16:37 jndi-doc.war
> > drwxr-xr-x 4 tomcatd tomcatd 512 Feb 17 06:42 jndi-examples
> > -rw-r--r-- 1 tomcatd tomcatd 33516 Feb 15 16:37 jndi-examples.war
> > -rw-r--r-- 1 tomcatd tomcatd 411591 Mar 1 06:09 jsp-tests.war
> > drwxr-xr-x 5 tomcatd tomcatd 512 Feb 18 09:06 manager
> > drwxr-xr-x 5 tomcatd tomcatd 512 Feb 17 06:42 request-doc
> > -rw-r--r-- 1 tomcatd tomcatd 159409 Feb 16 13:25 request-doc.war
> > drwxr-xr-x 4 tomcatd tomcatd 512 Feb 17 06:42 request-examples
> > -rw-r--r-- 1 tomcatd tomcatd 36690 Feb 16 13:25
> request-examples.war
> > -rw-r--r-- 1 tomcatd tomcatd 51150 Feb 26 20:36 scrape-doc.war
> > -rw-r--r-- 1 tomcatd tomcatd 86902 Feb 26 20:36 scrape-examples.war
> > drwxr-xr-x 5 tomcatd tomcatd 512 Feb 18 09:06 webdav
> >
> > ls of webapps after starting tomcat, all war files are expanded.
> >
> > $ ls -l webapps
> > total 1094
> > drwxr-xr-x 9 tomcatd tomcatd 512 Feb 18 09:06 ROOT
> > drwxr-xr-x 8 tomcatd tomcatd 512 Feb 18 09:06 examples
> > drwxr-xr-x 5 tomcatd tomcatd 512 Feb 17 06:42 jdbc-doc
> > -rw-r--r-- 1 tomcatd tomcatd 168332 Feb 15 16:19 jdbc-doc.war
> > drwxr-xr-x 4 tomcatd tomcatd 512 Feb 25 20:27 jdbc-examples
> > -rw-r--r-- 1 tomcatd tomcatd 39156 Feb 15 16:19 jdbc-examples.war
> > drwxr-xr-x 5 tomcatd tomcatd 512 Feb 16 13:20 jndi-doc
> > -rw-r--r-- 1 tomcatd tomcatd 79042 Feb 15 16:37 jndi-doc.war
> > drwxr-xr-x 4 tomcatd tomcatd 512 Feb 17 06:42 jndi-examples
> > -rw-r--r-- 1 tomcatd tomcatd 33516 Feb 15 16:37 jndi-examples.war
> > drwxr-xr-x 5 tomcatd tomcatd 512 Mar 1 08:27 jsp-tests
> > -rw-r--r-- 1 tomcatd tomcatd 411591 Mar 1 06:09 jsp-tests.war
> > drwxr-xr-x 5 tomcatd tomcatd 512 Feb 18 09:06 manager
> > drwxr-xr-x 5 tomcatd tomcatd 512 Feb 17 06:42 request-doc
> > -rw-r--r-- 1 tomcatd tomcatd 159409 Feb 16 13:25 request-doc.war
> > drwxr-xr-x 4 tomcatd tomcatd 512 Feb 17 06:42 request-examples
> > -rw-r--r-- 1 tomcatd tomcatd 36690 Feb 16 13:25
> request-examples.war
> > drwxr-xr-x 5 tomcatd tomcatd 512 Mar 1 08:28 scrape-doc
> > -rw-r--r-- 1 tomcatd tomcatd 51150 Feb 26 20:36 scrape-doc.war
> > drwxr-xr-x 4 tomcatd tomcatd 512 Mar 1 08:28 scrape-examples
> > -rw-r--r-- 1 tomcatd tomcatd 86902 Feb 26 20:36 scrape-examples.war
> > drwxr-xr-x 5 tomcatd tomcatd 512 Feb 18 09:06 webdav
> >
> > ls of webapps after stopping tomcat, notice that the war files that
> > tomcat had expanded out now have their directories removed.
> >
> > $ ls -l webapps
> > total 1091
> > drwxr-xr-x 9 tomcatd tomcatd 512 Feb 18 09:06 ROOT
> > drwxr-xr-x 8 tomcatd tomcatd 512 Feb 18 09:06 examples
> > drwxr-xr-x 5 tomcatd tomcatd 512 Feb 17 06:42 jdbc-doc
> > -rw-r--r-- 1 tomcatd tomcatd 168332 Feb 15 16:19 jdbc-doc.war
> > drwxr-xr-x 4 tomcatd tomcatd 512 Feb 25 20:27 jdbc-examples
> > -rw-r--r-- 1 tomcatd tomcatd 39156 Feb 15 16:19 jdbc-examples.war
> > drwxr-xr-x 5 tomcatd tomcatd 512 Feb 16 13:20 jndi-doc
> > -rw-r--r-- 1 tomcatd tomcatd 79042 Feb 15 16:37 jndi-doc.war
> > drwxr-xr-x 4 tomcatd tomcatd 512 Feb 17 06:42 jndi-examples
> > -rw-r--r-- 1 tomcatd tomcatd 33516 Feb 15 16:37 jndi-examples.war
> > -rw-r--r-- 1 tomcatd tomcatd 411591 Mar 1 06:09 jsp-tests.war
> > drwxr-xr-x 5 tomcatd tomcatd 512 Feb 18 09:06 manager
> > drwxr-xr-x 5 tomcatd tomcatd 512 Feb 17 06:42 request-doc
> > -rw-r--r-- 1 tomcatd tomcatd 159409 Feb 16 13:25 request-doc.war
> > drwxr-xr-x 4 tomcatd tomcatd 512 Feb 17 06:42 request-examples
> > -rw-r--r-- 1 tomcatd tomcatd 36690 Feb 16 13:25
> request-examples.war
> > -rw-r--r-- 1 tomcatd tomcatd 51150 Feb 26 20:36 scrape-doc.war
> > -rw-r--r-- 1 tomcatd tomcatd 86902 Feb 26 20:36 scrape-examples.war
> > drwxr-xr-x 5 tomcatd tomcatd 512 Feb 18 09:06 webdav
> >
> > What is the point in having Tomcat 4 unpack the war files if it removes
> > the unpacked war file directory when Tomcat stops?
>
> I think it was to make it equivalent to running the web application directly
> from the WAR.
> Now that we actually *can* run webapps from a WAR (as long as they don't
> involve JSPs, because Jasper relies too much on getPathTranslated and
> getRealPath), it could be useful to not remove the expanded WARs anymore.
> After that is fixed, I suggest setting unpackWARs to false as the default.
>
> > Why are some unpacked war file directories removed, and others are left
> alone?
> >
> > What if you modified the web application you installed, or it manages some
> > properties files in its own WEB-INF/classes directory?
> >
> > Is this the expected behaviour?
>
> Up until now, yes (it's definitely not a bug).
> We could consider changing this behavior (after beta 2).
>
> Remy
>
>
I consider this a bug. Tomcat should not be removing contexts that have
been expanded out into a directory in webapps.
If unpackWARs="false", then nothing is expanded out into webapss, the war
file is expanded out as needed into the work dir, correct?
But if unpackWARs="true", what should the behaviour be in the following cases:
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, or an updated war file for was installed and the directory
is for the previously expanded version. What now?
And when tomcat is shutdown it should not remove any unpacked war files,
this can significantly increase the time it takes tomcat to startup/shutdown.
Regards,
Glenn
----------------------------------------------------------------------
Glenn Nielsen glenn@more.net | /* Spelin donut madder |
MOREnet System Programming | * if iz ina coment. |
Missouri Research and Education Network | */ |
----------------------------------------------------------------------
Re: Tomcat 4 unpacking of WAR files behavior
Posted by Remy Maucherat <re...@apache.org>.
> What is the expected behaviour of Tomcat 4 when starting/stopping
> in regards to unpacking war files.
>
> I noticed what to me seems like strange behaviour.
>
> The Host is configured in server.xml with unpackWARs="true".
>
> ls of webapps before starting tomcat, notice that some of the war
> files are not expanded out.
>
> $ ls -l webapps
> total 1091
> drwxr-xr-x 9 tomcatd tomcatd 512 Feb 18 09:06 ROOT
> drwxr-xr-x 8 tomcatd tomcatd 512 Feb 18 09:06 examples
> drwxr-xr-x 5 tomcatd tomcatd 512 Feb 17 06:42 jdbc-doc
> -rw-r--r-- 1 tomcatd tomcatd 168332 Feb 15 16:19 jdbc-doc.war
> drwxr-xr-x 4 tomcatd tomcatd 512 Feb 25 20:27 jdbc-examples
> -rw-r--r-- 1 tomcatd tomcatd 39156 Feb 15 16:19 jdbc-examples.war
> drwxr-xr-x 5 tomcatd tomcatd 512 Feb 16 13:20 jndi-doc
> -rw-r--r-- 1 tomcatd tomcatd 79042 Feb 15 16:37 jndi-doc.war
> drwxr-xr-x 4 tomcatd tomcatd 512 Feb 17 06:42 jndi-examples
> -rw-r--r-- 1 tomcatd tomcatd 33516 Feb 15 16:37 jndi-examples.war
> -rw-r--r-- 1 tomcatd tomcatd 411591 Mar 1 06:09 jsp-tests.war
> drwxr-xr-x 5 tomcatd tomcatd 512 Feb 18 09:06 manager
> drwxr-xr-x 5 tomcatd tomcatd 512 Feb 17 06:42 request-doc
> -rw-r--r-- 1 tomcatd tomcatd 159409 Feb 16 13:25 request-doc.war
> drwxr-xr-x 4 tomcatd tomcatd 512 Feb 17 06:42 request-examples
> -rw-r--r-- 1 tomcatd tomcatd 36690 Feb 16 13:25
request-examples.war
> -rw-r--r-- 1 tomcatd tomcatd 51150 Feb 26 20:36 scrape-doc.war
> -rw-r--r-- 1 tomcatd tomcatd 86902 Feb 26 20:36 scrape-examples.war
> drwxr-xr-x 5 tomcatd tomcatd 512 Feb 18 09:06 webdav
>
> ls of webapps after starting tomcat, all war files are expanded.
>
> $ ls -l webapps
> total 1094
> drwxr-xr-x 9 tomcatd tomcatd 512 Feb 18 09:06 ROOT
> drwxr-xr-x 8 tomcatd tomcatd 512 Feb 18 09:06 examples
> drwxr-xr-x 5 tomcatd tomcatd 512 Feb 17 06:42 jdbc-doc
> -rw-r--r-- 1 tomcatd tomcatd 168332 Feb 15 16:19 jdbc-doc.war
> drwxr-xr-x 4 tomcatd tomcatd 512 Feb 25 20:27 jdbc-examples
> -rw-r--r-- 1 tomcatd tomcatd 39156 Feb 15 16:19 jdbc-examples.war
> drwxr-xr-x 5 tomcatd tomcatd 512 Feb 16 13:20 jndi-doc
> -rw-r--r-- 1 tomcatd tomcatd 79042 Feb 15 16:37 jndi-doc.war
> drwxr-xr-x 4 tomcatd tomcatd 512 Feb 17 06:42 jndi-examples
> -rw-r--r-- 1 tomcatd tomcatd 33516 Feb 15 16:37 jndi-examples.war
> drwxr-xr-x 5 tomcatd tomcatd 512 Mar 1 08:27 jsp-tests
> -rw-r--r-- 1 tomcatd tomcatd 411591 Mar 1 06:09 jsp-tests.war
> drwxr-xr-x 5 tomcatd tomcatd 512 Feb 18 09:06 manager
> drwxr-xr-x 5 tomcatd tomcatd 512 Feb 17 06:42 request-doc
> -rw-r--r-- 1 tomcatd tomcatd 159409 Feb 16 13:25 request-doc.war
> drwxr-xr-x 4 tomcatd tomcatd 512 Feb 17 06:42 request-examples
> -rw-r--r-- 1 tomcatd tomcatd 36690 Feb 16 13:25
request-examples.war
> drwxr-xr-x 5 tomcatd tomcatd 512 Mar 1 08:28 scrape-doc
> -rw-r--r-- 1 tomcatd tomcatd 51150 Feb 26 20:36 scrape-doc.war
> drwxr-xr-x 4 tomcatd tomcatd 512 Mar 1 08:28 scrape-examples
> -rw-r--r-- 1 tomcatd tomcatd 86902 Feb 26 20:36 scrape-examples.war
> drwxr-xr-x 5 tomcatd tomcatd 512 Feb 18 09:06 webdav
>
> ls of webapps after stopping tomcat, notice that the war files that
> tomcat had expanded out now have their directories removed.
>
> $ ls -l webapps
> total 1091
> drwxr-xr-x 9 tomcatd tomcatd 512 Feb 18 09:06 ROOT
> drwxr-xr-x 8 tomcatd tomcatd 512 Feb 18 09:06 examples
> drwxr-xr-x 5 tomcatd tomcatd 512 Feb 17 06:42 jdbc-doc
> -rw-r--r-- 1 tomcatd tomcatd 168332 Feb 15 16:19 jdbc-doc.war
> drwxr-xr-x 4 tomcatd tomcatd 512 Feb 25 20:27 jdbc-examples
> -rw-r--r-- 1 tomcatd tomcatd 39156 Feb 15 16:19 jdbc-examples.war
> drwxr-xr-x 5 tomcatd tomcatd 512 Feb 16 13:20 jndi-doc
> -rw-r--r-- 1 tomcatd tomcatd 79042 Feb 15 16:37 jndi-doc.war
> drwxr-xr-x 4 tomcatd tomcatd 512 Feb 17 06:42 jndi-examples
> -rw-r--r-- 1 tomcatd tomcatd 33516 Feb 15 16:37 jndi-examples.war
> -rw-r--r-- 1 tomcatd tomcatd 411591 Mar 1 06:09 jsp-tests.war
> drwxr-xr-x 5 tomcatd tomcatd 512 Feb 18 09:06 manager
> drwxr-xr-x 5 tomcatd tomcatd 512 Feb 17 06:42 request-doc
> -rw-r--r-- 1 tomcatd tomcatd 159409 Feb 16 13:25 request-doc.war
> drwxr-xr-x 4 tomcatd tomcatd 512 Feb 17 06:42 request-examples
> -rw-r--r-- 1 tomcatd tomcatd 36690 Feb 16 13:25
request-examples.war
> -rw-r--r-- 1 tomcatd tomcatd 51150 Feb 26 20:36 scrape-doc.war
> -rw-r--r-- 1 tomcatd tomcatd 86902 Feb 26 20:36 scrape-examples.war
> drwxr-xr-x 5 tomcatd tomcatd 512 Feb 18 09:06 webdav
>
> What is the point in having Tomcat 4 unpack the war files if it removes
> the unpacked war file directory when Tomcat stops?
I think it was to make it equivalent to running the web application directly
from the WAR.
Now that we actually *can* run webapps from a WAR (as long as they don't
involve JSPs, because Jasper relies too much on getPathTranslated and
getRealPath), it could be useful to not remove the expanded WARs anymore.
After that is fixed, I suggest setting unpackWARs to false as the default.
> Why are some unpacked war file directories removed, and others are left
alone?
>
> What if you modified the web application you installed, or it manages some
> properties files in its own WEB-INF/classes directory?
>
> Is this the expected behaviour?
Up until now, yes (it's definitely not a bug).
We could consider changing this behavior (after beta 2).
Remy