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]

Reply via email to