Please open a bug report,
then we can better discuss the issue.
Peter
Am 14.03.2006 um 16:21 schrieb Reinhard Moosauer:
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]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
