"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 [EMAIL PROTECTED] | /* Spelin donut madder |
MOREnet System Programming | * if iz ina coment. |
Missouri Research and Education Network | */ |
----------------------------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
