tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Glenn Nielsen <>
Subject Re: Tomcat 4.1-dev Host unpackWARs not working
Date Fri, 01 Mar 2002 01:37:21 GMT

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.

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.

There are certain ways the current implementation works that I really
hate.  And has been a source of confusion for my customers.

To make my customer support easier Tomcat needs to have well defined,
well documented, and consistent behaviour when managing web apps.

A few more comments intermixed below.



Remy Maucherat wrote:
> -1 for this proposal (sorry, but I really *hate* it).

Thanks, considering that a great deal of it was implemented by
me after I made it, and is still in place.

> 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.

> -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.  

> Note: remove/start/stop already exist.

Right, because I added them after I made that proposal back on 3/13/01.

Glenn Nielsen    | /* Spelin donut madder    |
MOREnet System Programming               |  * if iz ina coment.      |
Missouri Research and Education Network  |  */                       |

To unsubscribe, e-mail:   <>
For additional commands, e-mail: <>

View raw message