> 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:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
