On Thu, 28 Feb 2002, Glenn Nielsen wrote:
> Date: Thu, 28 Feb 2002 10:57:55 -0600
> From: Glenn Nielsen <[EMAIL PROTECTED]>
> Reply-To: Tomcat Developers List <[EMAIL PROTECTED]>
> To: Tomcat Developers List <[EMAIL PROTECTED]>
> 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 <[EMAIL PROTECTED]>
> > > Reply-To: Tomcat Developers List <[EMAIL PROTECTED]>
> > > To: [EMAIL PROTECTED]
> > > 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:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
