Hi Peter, thanks for making it clear.
I would appreciate your opinon in how we could enhance this: - I think, even on production systems, there should be a possibility to do a 'soft' application update without interrupting all users. When only minor changes in the application are made, the session state should be fully compatible. - I agree, that in many situations, a clear state is very much helpful. But this applies even more to development systems, doesn't it? - I hoped, we could simply add a manager attribute 'keepSessions' to the undeploy-task. But I am afraid, that's no easy to get, because deletion is not done in the manager but in the context. Do you think its possible? - It would be quite straightforward, if the 'update'-attribute to manager-deploy would have just this effect. If anyone has a good idea how to do this, please let me know. All other please vote for this enhancement because we have lost a very nice feature here. kind regards, Reinhard Am Dienstag, 14. März 2006 15:44 schrieb Peter Rossbach: > Hmm, > > I thing you are right. > > ContextConfig.destroy() remove the working dir after undeploy the app. > > /** > * Process a "destroy" event for this Context. > */ > protected synchronized void destroy() { > // Called from StandardContext.destroy() > if (log.isDebugEnabled()) > log.debug(sm.getString("contextConfig.destroy")); > > // Changed to getWorkPath per Bugzilla 35819. > String workDir = ((StandardContext) context).getWorkPath(); > if (workDir != null) > ExpandWar.delete(new File(workDir)); > } > > This feature is important do guaranty a clear state after change the > binary. Feel free to open > an enhancement bug report, and feel free to add a patch. The current > behaviour is > correct for production sites. > > Peter > > Am 14.03.2006 um 15:03 schrieb Reinhard Moosauer: > > Hi List, > > > > I found something, that looked promising, but did not work. > > Developers, please look, this could be a bug: > > > > The deploy-task has an attribute "update", removes the context before > > re-installing it. I hoped that this one would do what I want. > > > > But unfortunately, it is equivalent to undeploy/deploy so my > > sessions are gone > > again. :-( > > > > Maybe I have to clarify, what I am doing with my sessions (for > > Rodrigo): > > > > I have all session-attribute in my application serializable, so > > that tomcat > > can save all session data to disk when the context or tomcat itself is > > stopped. > > At startup these serialized data is being read back by tomcat > > automatically. > > As a result, users can coutinue their work exactly where the are. > > (Except that the application is not available for 1-2 seconds. But > > it is still > > unlikely that a users fires a request just in this moment, at least > > for > > medium-frequency apps) > > Formerly, the persisted session data survived the remove, so I could > > re-install the app. > > > > Please help! > > > > Reinhard > > > > Am Dienstag, 14. März 2006 13:53 schrieb Reinhard Moosauer: > >> Hello List, > >> > >> recently I upgraded from tomcat 5.5.9 to 5.5.15 > >> Since then, all my sessions are lost after a remove/install via the > >> manager. > >> > >> The problem is the following: > >> I installed a war-file, which is copied to the webapps-folder during > >> manager-install. When I want to replace the war with a new version, I > >> _have_ to undeploy, which deletes my persistent sessions too. > >> > >> How can I get back the smooth behavior of 5.5.9, which allowed me an > >> application update on the fly without disturbing user sessions? > >> > >> many thanks in advance for your advice > >> > >> Reinhard > >> > >> --------------------------------------------------------------------- > >> To unsubscribe, e-mail: [EMAIL PROTECTED] > >> For additional commands, e-mail: [EMAIL PROTECTED] > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > For additional commands, e-mail: [EMAIL PROTECTED] > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]