tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Craig R. McClanahan" <craig...@apache.org>
Subject Re: Tomcat 4.1-dev Host unpackWARs not working
Date Thu, 28 Feb 2002 19:33:00 GMT


On Thu, 28 Feb 2002, Glenn Nielsen wrote:

> Date: Thu, 28 Feb 2002 10:57:55 -0600
> From: Glenn Nielsen <glenn@voyager.apg.more.net>
> Reply-To: Tomcat Developers List <tomcat-dev@jakarta.apache.org>
> To: Tomcat Developers List <tomcat-dev@jakarta.apache.org>
> 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 <glenn@voyager.apg.more.net>
> > > Reply-To: Tomcat Developers List <tomcat-dev@jakarta.apache.org>
> > > To: tomcat-dev@jakarta.apache.org
> > > Subject: Tomcat 4.1-dev Host unpackWARs not working
> > >
> > > The Host attribute unpackWARs="true" is not working in the Tomcat 4 HEAD CVS
> > > version.
> > >
> > > I think it is due to the following at line 232 in StandardHostDeployer.java
> > > 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.)
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.

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.

> There are three ways listed in the manager docs.  A file url, a jar:file url
> and a remote jar url.  The remote jar url does follow the Host config for
> unpackWARs, the jar:file doesn't.
>
> I think the manager should follow the Host config explicitely.  If the
> person using the manager wants to override this, then that should be
> another parameter to the install, i.e. install?path=jar:file:/path-to-war&unpack=false
>
> > I will update the docs on unpackWARs to note that it only applies to
> > auto-deployed apps (from the appBase directory) at startup time.
> >
> > > Regards,
> > >
> > > Glenn
> > >
> >
> > Craig
> >

Craig



--
To unsubscribe, e-mail:   <mailto:tomcat-dev-unsubscribe@jakarta.apache.org>
For additional commands, e-mail: <mailto:tomcat-dev-help@jakarta.apache.org>


Mime
View raw message