Mailing-List: contact tomcat-dev-help@jakarta.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Tomcat Developers List" <tomcat-dev@jakarta.apache.org>
Message-ID: <00f401c1c0fa$d5eeab70$6501a8c0@apache.org>
From: "Remy Maucherat" <remm@apache.org>
To: "Tomcat Developers List" <tomcat-dev@jakarta.apache.org>
References: <20020228105311.G98856-100000@icarus.apache.org>
 <3C7E9234.7B3992EA@voyager.apg.more.net>
 <004101c1c0a7$b17bda40$6501a8c0@apache.org>
 <3C7EDB51.7005F769@voyager.apg.more.net>
Subject: Re: Tomcat 4.1-dev Host unpackWARs not working
Date: Fri, 1 Mar 2002 00:26:49 -0800
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit

> Remy,
>
> I posted that _OLD_ proposal from 3/13/01 as an example of how I
> documented the behaviour of tomcat for managing web apps.  It was
> not meant as a current proposal.  Just as a place to start a discussion.

Well, I didn't like it so far.

> Could either you or Craig fully document what the expected behaviour is,
> then perhaps we can have a good discussion on how it can be improved.

The thing is that I don't think it can be improved without introducing some
unpredictability.

> > To paraphrase a bit:
> > If unpack="false" then unpack.
> > If unpack="true" then unpack somewhere else.
> > Otehrwise, both do the same.
> >
> > The current behavior will hopefully encourage people not to rely on the
> > filesystem and use more portable APIs (a good thing IMO).
> >
> > -1 for removing expanded webapps on shutdown. You don't know if the user
> > modified something, and would like to see its modifications survive the
> > shutdown.
>
> The old proposal didn't say that.
>
> > At least unpack="false" currently makes things very clear, since the
user
> > can't modify anything without unpacking himself.
> >
>
> Right, except that isn't the way my customers will use it.  They want
> to be able to update files within the deployed app if needed to change
> a JSP, etc.

I won't let them if unpack="false" (the WAR will be packed). Otherwise, set
it to true (the WAR will be unpacked). It seems a bit obvious ...

> > -1 for update as a new manager command. Its behavior seems highly
> > unpredictable to me. remove + install seems better, so that the user
knows
> > what he's doing.
> >
>
> I think update is an important feature to add.  A customer may need to
update
> the application but retain any data related to that application.  In that
> case they wouldn't want to do an install/remove.  I think it can be done
in
> a predictable manner.

I doubt it at this point. I'm not in favor of adding any intelligence and
do-stuff-behind-your-back features in the deployer.

Remy


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