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]
