You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tomcat.apache.org by Glenn Nielsen <gl...@voyager.apg.more.net> on 2002/03/01 02:37:21 UTC
Re: Tomcat 4.1-dev Host unpackWARs not working
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.
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.
Regards,
Glenn
Remy Maucherat wrote:
>
> > [PROPOSAL]
>
> -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 glenn@more.net | /* Spelin donut madder |
MOREnet System Programming | * if iz ina coment. |
Missouri Research and Education Network | */ |
----------------------------------------------------------------------
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Tomcat 4.1-dev Host unpackWARs not working
Posted by Glenn Nielsen <gl...@voyager.apg.more.net>.
Remy Maucherat wrote:
>
> > 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 ...
>
Except that isn't true all the time. In some cases the manager will override
the Host configuration setting of unpackWARs="true" and _not_ unpack them.
> > > -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.
>
Its not do-stuff-behind-your-back if how it does an update is well documented.
Glenn
----------------------------------------------------------------------
Glenn Nielsen glenn@more.net | /* Spelin donut madder |
MOREnet System Programming | * if iz ina coment. |
Missouri Research and Education Network | */ |
----------------------------------------------------------------------
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Tomcat 4.1-dev Host unpackWARs not working
Posted by Remy Maucherat <re...@apache.org>.
> 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: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>