RE: sessionS info persistence when restart Tomcat

[Steve Kirk]

I have answered one of the points below myself with more testing:
HttpSessionActivationListener#sessionWillPassivate seems to work slightly
different to the other Listeners in that its methods are only called when
they are an object bound to the session is an instance of the
HttpSessionActivationListener.  The javadocs actually do say this, but I
didn't take it in at first: Objects that are bound to a session may listen
to container events notifying them that sessions will be passivated and that
session will be activated. A container that migrates session between VMs or
persists sessions is required to notify all attributes bound to sessions
implementing HttpSessionActivationListener.

Thus HttpSessionActivationListener works slightly differently to
HttpSessionListener for example, because the latter's sessionCreated and
sessionDestroyed methods are called irrespective of whether they are methods
of objects bound within the session or not.

However I'd still appreciate any help that anyone can give on the other
points below :)

 -Original Message-
 From: Steve Kirk [mailto:[EMAIL PROTECTED] 
 Sent: Friday 10 December 2004 05:50
 To: 'Tomcat Users List'
 Subject: RE: sessionS info persistence when restart Tomcat
 
 
 
 OK well after a few weeks' break from it I've returned to 
 this problem with
 fresh eyes, and immediately found out something interesting.
 
 I normally run TC (5.0.28) as a windows service.  So upon 
 re-reading this
 thread, Yoav's earlier comment stood out as something I 
 hadn't checked, so I
 ran TC using the startup and shutdown scripts instead.  I 
 have a simple test
 class which listens for the context/session events and logs 
 them.  This
 shows that the following things happen when running from the 
 DOS scripts,
 which do not happen when running as a service:
 
 contextDestroyed is called when TC shuts down
 sessions are serialised to SESSIONS.ser when TC is stopped
 java.io.NotSerializableException is thrown when a session 
 object is not
 serializable
 
 So I guess Yoav's point below from earlier in the thread 
 could be correct
 after all - these could be outstanding bugs.  However I couldn't find
 anything in Bugzilla.
 
 A second point is that 
 HttpSessionActivationListener#sessionWillPassivate is
 still not being called, even when start/stopping TC from the 
 DOS scripts,
 and whether or not there are any object stored in the session 
 (I store a
 simple String in the session for test purposes).  I can't think what's
 wrong, unless I am using HttpSessionActivationListener 
 incorrectly?  I have
 just added it as another interface implemented by my Listener 
 class along
 with the other Listener interfaces (HttpSessionListener,
 HttpSessionAttributeListener, ServletContextListener), is 
 this correct?
 
 A third point (and perhaps wandering slightly now) is raised 
 by the logged
 NotSerializiableException message: 
 
 INFO: Cannot serialize session attribute LOGGED_IN_USER for session
 58FD0ECF29BDCEB9DC096C5DF57A1DCC
 java.io.NotSerializableException: core.servlet.processor.SubmitLogin
 at
 java.io.ObjectOutputStream.writeObject0(ObjectOutputStream.java:1054)
 
 this message is odd in that it refers to one of my classes 
 (SubmitLogin)
 which, to my mind, has nothing to do with serialisation 
 issues.  What does
 the error message mean when it quotes my class name
 (core.servlet.processor.SubmitLogin) as the error message?  I 
 know that this
 is certainly *not* the class of any object stored in the 
 session - I have
 checked this from my event listening class's logs - I write 
 all the session
 attributes to the log as each one is added.
 
 Obviously I need to fix my unserialisable session object, but 
 aside from
 that, it does seem from all the above as though session events and
 exceptions are handled differently when TC runs as a windows service
 compared to from the DOS scripts.  Also I have the problem that
 sessionWillPassivate still does not seem to be called.
 
 Any help much appreciated :)
 
  -Original Message-
  From: Ben Souther [mailto:[EMAIL PROTECTED] 
  Sent: Friday 05 November 2004 14:52
  To: Tomcat Users List
  Subject: RE: sessionS info persistence when restart Tomcat
  
  
  On Fri, 2004-11-05 at 08:29, Shapira, Yoav wrote:
   Hi,
   Are you running Tomcat as a windows service?  If so 
 there's an open
   issue with it not calling certain destroy methods on shutdown.
   
   Yoav Shapira http://www.yoavshapira.com
  I believe that issue was with contextDestroyed not being 
  called and was
  tested under 5.0.8 and 5.5.x and working.
  
   
   -Original Message-
   From: Ben Souther [mailto:[EMAIL PROTECTED]
   Sent: Thursday, November 04, 2004 9:22 PM
   To: Tomcat Users List
   Subject: RE: sessionS info persistence when restart Tomcat
   
   SessionDestroyed shouldn't be called when tomcat shuts 
  down. Otherwise,
   the session wouldn't be valid when it starts up.  I just 
  tested with a
   clean install

RE: sessionS info persistence when restart Tomcat

[Shapira, Yoav]

Hi,
Tomcat is not throwing that exception just because it feels like it.  An
instance of that class must be reachable in the serialization process of
at least of the session attributes.

Yoav Shapira http://www.yoavshapira.com


-Original Message-
From: Steve Kirk [mailto:[EMAIL PROTECTED]
Sent: Friday, December 10, 2004 8:25 AM
To: 'Tomcat Users List'
Subject: RE: sessionS info persistence when restart Tomcat


no.  I've checked this by adding more debug code to my SessionLogger
class
(which implements all the Listener interfaces).  Every time a session
event
is fired, my listener code lists all the session attribute names and
values
to the log.  So when I shutdown TC, the log output looks like this:

2004-12-10 12:08:25 StandardContext[/ao]*** SESSION EVENT:
sessionWillPassivate,
[EMAIL PROTECTED]
2004-12-10 12:08:25 StandardContext[/ao]logSessionAttributes() called
2004-12-10 12:08:25 StandardContext[/ao]session
attribute:TEST1=TestString
2004-12-10 12:08:25 StandardContext[/ao]session
attribute:[EMAIL PROTECTED]
2004-12-10 12:08:25 StandardContext[/ao]session
attribute:LOGGED_IN_USER=[ID=1,TS='2004-09-15
18:14:33.0',GUIDELINEFILENAME='user1.html',COMPANYID='0',FIRSTNAME='sup
er',
L
ASTNAME='user',TITLE='superuser',KNOWNAS='superuser',EMAILADDRESS='ao.s
uper
u
[EMAIL PROTECTED]',PHONE='01234 superuser',MOBILE='0
super',USERNAME='su',PASSWORD='super',ACTIVE='Y',BRANDID='1']
2004-12-10 12:08:25 StandardContext[/ao]num attributes:3

So the object named in the log message is not in the session.  What is
in
the session is core.sql.bean.User, which is a class of my own design
that
basically just has a load of data fields in it (String, Timestamp,
int).
The blurb you can see in the log is the output of the toString()
method,
which just concats the fields together.  It's parent and subclasses are
all
Serializable.  So is the SessionLogger itself.

 -Original Message-
 From: Ben Souther [mailto:[EMAIL PROTECTED]
 Sent: Friday 10 December 2004 13:14
 To: Tomcat Users List
 Subject: RE: sessionS info persistence when restart Tomcat


  INFO: Cannot serialize session attribute LOGGED_IN_USER
   for session 58FD0ECF29BDCEB9DC096C5DF57A1DCC
   java.io.NotSerializableException:
   core.servlet.processor.SubmitLogin
   at

  is certainly *not* the class of any object stored in the
  session - I have

 Do you have a reference to it in any of the objects stored in your
 session?









 -
 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]




This e-mail, including any attachments, is a confidential business 
communication, and may contain information that is confidential, proprietary 
and/or privileged.  This e-mail is intended only for the individual(s) to whom 
it is addressed, and may not be saved, copied, printed, disclosed or used by 
anyone else.  If you are not the(an) intended recipient, please immediately 
delete this e-mail from your computer system and notify the sender.  Thank you.


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

RE: sessionS info persistence when restart Tomcat

[Steve Kirk]

You are of course right ;)  I was just experiencing temporary blindness.

I had overlooked an underlying grandparent class of my User class which was
in the Session; the grandparent contains a reference to its creator, which
is the culprit mentioned in the Exception.  This in itself is a nasty that I
wasn't aware of, so that's 2 things to fix now.

All solved now :) thanks Yoav/Ben.

 -Original Message-
 From: Shapira, Yoav [mailto:[EMAIL PROTECTED] 
 Sent: Friday 10 December 2004 14:03
 To: Tomcat Users List
 Subject: RE: sessionS info persistence when restart Tomcat
 
 
 
 Hi,
 Tomcat is not throwing that exception just because it feels 
 like it.  An
 instance of that class must be reachable in the serialization 
 process of
 at least of the session attributes.
 
 Yoav Shapira http://www.yoavshapira.com
  
 
 -Original Message-
 From: Steve Kirk [mailto:[EMAIL PROTECTED]
 Sent: Friday, December 10, 2004 8:25 AM
 To: 'Tomcat Users List'
 Subject: RE: sessionS info persistence when restart Tomcat
 
 
 no.  I've checked this by adding more debug code to my SessionLogger
 class
 (which implements all the Listener interfaces).  Every time a session
 event
 is fired, my listener code lists all the session attribute names and
 values
 to the log.  So when I shutdown TC, the log output looks like this:
 
 2004-12-10 12:08:25 StandardContext[/ao]*** SESSION EVENT:
 sessionWillPassivate,
 [EMAIL PROTECTED]
 2004-12-10 12:08:25 StandardContext[/ao]logSessionAttributes() called
 2004-12-10 12:08:25 StandardContext[/ao]session
 attribute:TEST1=TestString
 2004-12-10 12:08:25 StandardContext[/ao]session
 attribute:[EMAIL PROTECTED]
 2004-12-10 12:08:25 StandardContext[/ao]session
 attribute:LOGGED_IN_USER=[ID=1,TS='2004-09-15
 18:14:33.0',GUIDELINEFILENAME='user1.html',COMPANYID='0',FIRS
 TNAME='sup
 er',
 L
 ASTNAME='user',TITLE='superuser',KNOWNAS='superuser',EMAILADD
 RESS='ao.s
 uper
 u
 [EMAIL PROTECTED]',PHONE='01234 superuser',MOBILE='0
 super',USERNAME='su',PASSWORD='super',ACTIVE='Y',BRANDID='1']
 2004-12-10 12:08:25 StandardContext[/ao]num attributes:3
 
 So the object named in the log message is not in the 
 session.  What is
 in
 the session is core.sql.bean.User, which is a class of my own design
 that
 basically just has a load of data fields in it (String, Timestamp,
 int).
 The blurb you can see in the log is the output of the toString()
 method,
 which just concats the fields together.  It's parent and 
 subclasses are
 all
 Serializable.  So is the SessionLogger itself.
 
  -Original Message-
  From: Ben Souther [mailto:[EMAIL PROTECTED]
  Sent: Friday 10 December 2004 13:14
  To: Tomcat Users List
  Subject: RE: sessionS info persistence when restart Tomcat
 
 
   INFO: Cannot serialize session attribute LOGGED_IN_USER
for session 58FD0ECF29BDCEB9DC096C5DF57A1DCC
java.io.NotSerializableException:
core.servlet.processor.SubmitLogin
at
 
   is certainly *not* the class of any object stored in the
   session - I have
 
  Do you have a reference to it in any of the objects stored in your
  session?
 
 
 
 
 
 
 
 
 
  
 -
  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]
 
 
 
 
 This e-mail, including any attachments, is a confidential 
 business communication, and may contain information that is 
 confidential, proprietary and/or privileged.  This e-mail is 
 intended only for the individual(s) to whom it is addressed, 
 and may not be saved, copied, printed, disclosed or used by 
 anyone else.  If you are not the(an) intended recipient, 
 please immediately delete this e-mail from your computer 
 system and notify the sender.  Thank you.
 
 
 -
 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]

RE: sessionS info persistence when restart Tomcat

[Shapira, Yoav]

Hi,
Glad you've solved it.  An extra tip on this issue: the commons-lang
(http://jakarta.apache.org/commons/lang/) SerializationUtils class is
useful in quickly testing whether a complex object graph can be
serialized or not.  I use it every now and then and it's been great.
Hopefully you or others might find it useful in the future.

Yoav Shapira http://www.yoavshapira.com


-Original Message-
From: Steve Kirk [mailto:[EMAIL PROTECTED]
Sent: Friday, December 10, 2004 2:19 PM
To: 'Tomcat Users List'
Subject: RE: sessionS info persistence when restart Tomcat


You are of course right ;)  I was just experiencing temporary
blindness.

I had overlooked an underlying grandparent class of my User class which
was
in the Session; the grandparent contains a reference to its creator,
which
is the culprit mentioned in the Exception.  This in itself is a nasty
that
I
wasn't aware of, so that's 2 things to fix now.

All solved now :) thanks Yoav/Ben.

 -Original Message-
 From: Shapira, Yoav [mailto:[EMAIL PROTECTED]
 Sent: Friday 10 December 2004 14:03
 To: Tomcat Users List
 Subject: RE: sessionS info persistence when restart Tomcat



 Hi,
 Tomcat is not throwing that exception just because it feels
 like it.  An
 instance of that class must be reachable in the serialization
 process of
 at least of the session attributes.

 Yoav Shapira http://www.yoavshapira.com


 -Original Message-
 From: Steve Kirk [mailto:[EMAIL PROTECTED]
 Sent: Friday, December 10, 2004 8:25 AM
 To: 'Tomcat Users List'
 Subject: RE: sessionS info persistence when restart Tomcat
 
 
 no.  I've checked this by adding more debug code to my SessionLogger
 class
 (which implements all the Listener interfaces).  Every time a
session
 event
 is fired, my listener code lists all the session attribute names and
 values
 to the log.  So when I shutdown TC, the log output looks like this:
 
 2004-12-10 12:08:25 StandardContext[/ao]*** SESSION EVENT:
 sessionWillPassivate,
 [EMAIL PROTECTED]
 2004-12-10 12:08:25 StandardContext[/ao]logSessionAttributes()
called
 2004-12-10 12:08:25 StandardContext[/ao]session
 attribute:TEST1=TestString
 2004-12-10 12:08:25 StandardContext[/ao]session
 attribute:[EMAIL PROTECTED]
 2004-12-10 12:08:25 StandardContext[/ao]session
 attribute:LOGGED_IN_USER=[ID=1,TS='2004-09-15
 18:14:33.0',GUIDELINEFILENAME='user1.html',COMPANYID='0',FIRS
 TNAME='sup
 er',
 L
 ASTNAME='user',TITLE='superuser',KNOWNAS='superuser',EMAILADD
 RESS='ao.s
 uper
 u
 [EMAIL PROTECTED]',PHONE='01234 superuser',MOBILE='0
 super',USERNAME='su',PASSWORD='super',ACTIVE='Y',BRANDID='1']
 2004-12-10 12:08:25 StandardContext[/ao]num attributes:3
 
 So the object named in the log message is not in the
 session.  What is
 in
 the session is core.sql.bean.User, which is a class of my own design
 that
 basically just has a load of data fields in it (String, Timestamp,
 int).
 The blurb you can see in the log is the output of the toString()
 method,
 which just concats the fields together.  It's parent and
 subclasses are
 all
 Serializable.  So is the SessionLogger itself.
 
  -Original Message-
  From: Ben Souther [mailto:[EMAIL PROTECTED]
  Sent: Friday 10 December 2004 13:14
  To: Tomcat Users List
  Subject: RE: sessionS info persistence when restart Tomcat
 
 
   INFO: Cannot serialize session attribute LOGGED_IN_USER
for session 58FD0ECF29BDCEB9DC096C5DF57A1DCC
java.io.NotSerializableException:
core.servlet.processor.SubmitLogin
at
 
   is certainly *not* the class of any object stored in the
   session - I have
 
  Do you have a reference to it in any of the objects stored in your
  session?
 
 
 
 
 
 
 
 
 
 
 -
  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]




 This e-mail, including any attachments, is a confidential
 business communication, and may contain information that is
 confidential, proprietary and/or privileged.  This e-mail is
 intended only for the individual(s) to whom it is addressed,
 and may not be saved, copied, printed, disclosed or used by
 anyone else.  If you are not the(an) intended recipient,
 please immediately delete this e-mail from your computer
 system and notify the sender.  Thank you.


 -
 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]




This e-mail, including any attachments, is a confidential business 
communication, and may contain information that is confidential, proprietary

RE: sessionS info persistence when restart Tomcat

[Ben Souther]

This is probably the bug you're talking about.
http://issues.apache.org/bugzilla/show_bug.cgi?id=29521



On Fri, 2004-12-10 at 04:19, Steve Kirk wrote:
 I have answered one of the points below myself with more testing:
 HttpSessionActivationListener#sessionWillPassivate seems to work slightly
 different to the other Listeners in that its methods are only called when
 they are an object bound to the session is an instance of the
 HttpSessionActivationListener.  The javadocs actually do say this, but I
 didn't take it in at first: Objects that are bound to a session may listen
 to container events notifying them that sessions will be passivated and that
 session will be activated. A container that migrates session between VMs or
 persists sessions is required to notify all attributes bound to sessions
 implementing HttpSessionActivationListener.
 
 Thus HttpSessionActivationListener works slightly differently to
 HttpSessionListener for example, because the latter's sessionCreated and
 sessionDestroyed methods are called irrespective of whether they are methods
 of objects bound within the session or not.
 
 However I'd still appreciate any help that anyone can give on the other
 points below :)
 
  -Original Message-
  From: Steve Kirk [mailto:[EMAIL PROTECTED] 
  Sent: Friday 10 December 2004 05:50
  To: 'Tomcat Users List'
  Subject: RE: sessionS info persistence when restart Tomcat
  
  
  
  OK well after a few weeks' break from it I've returned to 
  this problem with
  fresh eyes, and immediately found out something interesting.
  
  I normally run TC (5.0.28) as a windows service.  So upon 
  re-reading this
  thread, Yoav's earlier comment stood out as something I 
  hadn't checked, so I
  ran TC using the startup and shutdown scripts instead.  I 
  have a simple test
  class which listens for the context/session events and logs 
  them.  This
  shows that the following things happen when running from the 
  DOS scripts,
  which do not happen when running as a service:
  
  contextDestroyed is called when TC shuts down
  sessions are serialised to SESSIONS.ser when TC is stopped
  java.io.NotSerializableException is thrown when a session 
  object is not
  serializable
  
  So I guess Yoav's point below from earlier in the thread 
  could be correct
  after all - these could be outstanding bugs.  However I couldn't find
  anything in Bugzilla.
  
  A second point is that 
  HttpSessionActivationListener#sessionWillPassivate is
  still not being called, even when start/stopping TC from the 
  DOS scripts,
  and whether or not there are any object stored in the session 
  (I store a
  simple String in the session for test purposes).  I can't think what's
  wrong, unless I am using HttpSessionActivationListener 
  incorrectly?  I have
  just added it as another interface implemented by my Listener 
  class along
  with the other Listener interfaces (HttpSessionListener,
  HttpSessionAttributeListener, ServletContextListener), is 
  this correct?
  
  A third point (and perhaps wandering slightly now) is raised 
  by the logged
  NotSerializiableException message: 
  
  INFO: Cannot serialize session attribute LOGGED_IN_USER for session
  58FD0ECF29BDCEB9DC096C5DF57A1DCC
  java.io.NotSerializableException: core.servlet.processor.SubmitLogin
  at
  java.io.ObjectOutputStream.writeObject0(ObjectOutputStream.java:1054)
  
  this message is odd in that it refers to one of my classes 
  (SubmitLogin)
  which, to my mind, has nothing to do with serialisation 
  issues.  What does
  the error message mean when it quotes my class name
  (core.servlet.processor.SubmitLogin) as the error message?  I 
  know that this
  is certainly *not* the class of any object stored in the 
  session - I have
  checked this from my event listening class's logs - I write 
  all the session
  attributes to the log as each one is added.
  
  Obviously I need to fix my unserialisable session object, but 
  aside from
  that, it does seem from all the above as though session events and
  exceptions are handled differently when TC runs as a windows service
  compared to from the DOS scripts.  Also I have the problem that
  sessionWillPassivate still does not seem to be called.
  
  Any help much appreciated :)
  
   -Original Message-
   From: Ben Souther [mailto:[EMAIL PROTECTED] 
   Sent: Friday 05 November 2004 14:52
   To: Tomcat Users List
   Subject: RE: sessionS info persistence when restart Tomcat
   
   
   On Fri, 2004-11-05 at 08:29, Shapira, Yoav wrote:
Hi,
Are you running Tomcat as a windows service?  If so 
  there's an open
issue with it not calling certain destroy methods on shutdown.

Yoav Shapira http://www.yoavshapira.com
   I believe that issue was with contextDestroyed not being 
   called and was
   tested under 5.0.8 and 5.5.x and working.
   

-Original Message-
From: Ben Souther [mailto:[EMAIL PROTECTED]
Sent: Thursday, November 04, 2004 9

RE: sessionS info persistence when restart Tomcat

[Steve Kirk]

Ben Souther said:
 
 This is probably the bug you're talking about.
 http://issues.apache.org/bugzilla/show_bug.cgi?id=29521
 
 
 

Aha.  Thanks Ben.  That clears up most of it in one go.

So it was fixed in 5.0.29 but as far as I can see (from the Jakarta news
page and the TC download page) there hasn't been a 5.0.x final release
since 5.0.28 (which I'm already running).  So am I right that if I don't
want to use beta releases, then to fix this I need to go to 5.5.4?  I
understand that the switch up to 5.5 brings in the need to make other
changes to my code, ISTR logging and some aspects of config are slightly
different?

Also, can anyone shed any light on my third point below please :

 A third point (and perhaps wandering slightly now) is raised 
 by the logged
 NotSerializiableException message: 
 
 INFO: Cannot serialize session attribute LOGGED_IN_USER 
 for session 58FD0ECF29BDCEB9DC096C5DF57A1DCC
 java.io.NotSerializableException: 
 core.servlet.processor.SubmitLogin
 at
 
 java.io.ObjectOutputStream.writeObject0(ObjectOutputStream.java:1054)
 
 this message is odd in that it refers to one of my classes 
 (SubmitLogin)
 which, to my mind, has nothing to do with serialisation 
 issues.  What does
 the error message mean when it quotes my class name
 (core.servlet.processor.SubmitLogin) as the error message?  I 
 know that this
 is certainly *not* the class of any object stored in the 
 session - I have
 checked this from my event listening class's logs - I write 
 all the session
 attributes to the log as each one is added.




-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

RE: sessionS info persistence when restart Tomcat

[Ben Souther]

 INFO: Cannot serialize session attribute LOGGED_IN_USER 
  for session 58FD0ECF29BDCEB9DC096C5DF57A1DCC
  java.io.NotSerializableException: 
  core.servlet.processor.SubmitLogin
  at

 is certainly *not* the class of any object stored in the 
 session - I have

Do you have a reference to it in any of the objects stored in your
session?









-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

RE: sessionS info persistence when restart Tomcat

[Steve Kirk]

no.  I've checked this by adding more debug code to my SessionLogger class
(which implements all the Listener interfaces).  Every time a session event
is fired, my listener code lists all the session attribute names and values
to the log.  So when I shutdown TC, the log output looks like this:

2004-12-10 12:08:25 StandardContext[/ao]*** SESSION EVENT:
sessionWillPassivate,
[EMAIL PROTECTED]
2004-12-10 12:08:25 StandardContext[/ao]logSessionAttributes() called
2004-12-10 12:08:25 StandardContext[/ao]session attribute:TEST1=TestString
2004-12-10 12:08:25 StandardContext[/ao]session
attribute:[EMAIL PROTECTED]
2004-12-10 12:08:25 StandardContext[/ao]session
attribute:LOGGED_IN_USER=[ID=1,TS='2004-09-15
18:14:33.0',GUIDELINEFILENAME='user1.html',COMPANYID='0',FIRSTNAME='super',L
ASTNAME='user',TITLE='superuser',KNOWNAS='superuser',EMAILADDRESS='ao.superu
[EMAIL PROTECTED]',PHONE='01234 superuser',MOBILE='0
super',USERNAME='su',PASSWORD='super',ACTIVE='Y',BRANDID='1']
2004-12-10 12:08:25 StandardContext[/ao]num attributes:3

So the object named in the log message is not in the session.  What is in
the session is core.sql.bean.User, which is a class of my own design that
basically just has a load of data fields in it (String, Timestamp, int).
The blurb you can see in the log is the output of the toString() method,
which just concats the fields together.  It's parent and subclasses are all
Serializable.  So is the SessionLogger itself.

 -Original Message-
 From: Ben Souther [mailto:[EMAIL PROTECTED] 
 Sent: Friday 10 December 2004 13:14
 To: Tomcat Users List
 Subject: RE: sessionS info persistence when restart Tomcat
 
 
  INFO: Cannot serialize session attribute LOGGED_IN_USER 
   for session 58FD0ECF29BDCEB9DC096C5DF57A1DCC
   java.io.NotSerializableException: 
   core.servlet.processor.SubmitLogin
   at
 
  is certainly *not* the class of any object stored in the 
  session - I have
 
 Do you have a reference to it in any of the objects stored in your
 session?
 
 
 
 
 
 
 
 
 
 -
 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]

RE: sessionS info persistence when restart Tomcat

[Ben Souther]

On Fri, 2004-12-10 at 14:18, Steve Kirk wrote:
 You are of course right ;)  I was just experiencing temporary blindness.
 
 I had overlooked an underlying grandparent class of my User class which was
 in the Session; the grandparent contains a reference to its creator, which
 is the culprit mentioned in the Exception.  This in itself is a nasty that I
 wasn't aware of, so that's 2 things to fix now.
 
 All solved now :) thanks Yoav/Ben.

Those pesky grandparents ;)

Glad you found it.


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

RE: sessionS info persistence when restart Tomcat

[Steve Kirk]

OK well after a few weeks' break from it I've returned to this problem with
fresh eyes, and immediately found out something interesting.

I normally run TC (5.0.28) as a windows service.  So upon re-reading this
thread, Yoav's earlier comment stood out as something I hadn't checked, so I
ran TC using the startup and shutdown scripts instead.  I have a simple test
class which listens for the context/session events and logs them.  This
shows that the following things happen when running from the DOS scripts,
which do not happen when running as a service:

contextDestroyed is called when TC shuts down
sessions are serialised to SESSIONS.ser when TC is stopped
java.io.NotSerializableException is thrown when a session object is not
serializable

So I guess Yoav's point below from earlier in the thread could be correct
after all - these could be outstanding bugs.  However I couldn't find
anything in Bugzilla.

A second point is that HttpSessionActivationListener#sessionWillPassivate is
still not being called, even when start/stopping TC from the DOS scripts,
and whether or not there are any object stored in the session (I store a
simple String in the session for test purposes).  I can't think what's
wrong, unless I am using HttpSessionActivationListener incorrectly?  I have
just added it as another interface implemented by my Listener class along
with the other Listener interfaces (HttpSessionListener,
HttpSessionAttributeListener, ServletContextListener), is this correct?

A third point (and perhaps wandering slightly now) is raised by the logged
NotSerializiableException message: 

INFO: Cannot serialize session attribute LOGGED_IN_USER for session
58FD0ECF29BDCEB9DC096C5DF57A1DCC
java.io.NotSerializableException: core.servlet.processor.SubmitLogin
at
java.io.ObjectOutputStream.writeObject0(ObjectOutputStream.java:1054)

this message is odd in that it refers to one of my classes (SubmitLogin)
which, to my mind, has nothing to do with serialisation issues.  What does
the error message mean when it quotes my class name
(core.servlet.processor.SubmitLogin) as the error message?  I know that this
is certainly *not* the class of any object stored in the session - I have
checked this from my event listening class's logs - I write all the session
attributes to the log as each one is added.

Obviously I need to fix my unserialisable session object, but aside from
that, it does seem from all the above as though session events and
exceptions are handled differently when TC runs as a windows service
compared to from the DOS scripts.  Also I have the problem that
sessionWillPassivate still does not seem to be called.

Any help much appreciated :)

 -Original Message-
 From: Ben Souther [mailto:[EMAIL PROTECTED] 
 Sent: Friday 05 November 2004 14:52
 To: Tomcat Users List
 Subject: RE: sessionS info persistence when restart Tomcat
 
 
 On Fri, 2004-11-05 at 08:29, Shapira, Yoav wrote:
  Hi,
  Are you running Tomcat as a windows service?  If so there's an open
  issue with it not calling certain destroy methods on shutdown.
  
  Yoav Shapira http://www.yoavshapira.com
 I believe that issue was with contextDestroyed not being 
 called and was
 tested under 5.0.8 and 5.5.x and working.
 
  
  -Original Message-
  From: Ben Souther [mailto:[EMAIL PROTECTED]
  Sent: Thursday, November 04, 2004 9:22 PM
  To: Tomcat Users List
  Subject: RE: sessionS info persistence when restart Tomcat
  
  SessionDestroyed shouldn't be called when tomcat shuts 
 down. Otherwise,
  the session wouldn't be valid when it starts up.  I just 
 tested with a
  clean install of 5.0.29 with a similar listener to the one you
  describe.
  SessionDestroyed was not called when I stopped TC but the 
 sessions were
  still valid when I started it up.  I can give you the war 
 file if you
  like.
  
  Do all of the attributes that you're adding to your 
 session implement
  Serializable?
  
   
 C:\jakarta-tomcat-5.0.28\work\Catalina\localhost\ao\SESSIONS.ser (The
  system cannot find the path specified)
  Does tomcat have sufficient permissions to write to the 
 work directory?
  
  How are you stopping Tomcat?
  
  
  
  On Thu, 2004-11-04 at 20:15, Steve Kirk wrote:
   Following Yoav's earlier comments I've implemented a basic class
   SessionLogger that implements HttpSessionListener,
   HttpSessionActivationListener, HttpSessionAttributeListener,
   ServletContextListener.  It just writes amessages to stdout using
   System.out.println() to log when each event fires, 
 including each of
  the
   interface events plus instantiation and finalization of 
 SessionLogger
   itself.  I've configured it in web.xml:
  
   listener
listener-classcore.servlet.SessionLogger/listener-class
   /listener
  
   SessionLogger logs its own presence OK when I instantiate it, and
  happily
   logs events as expected on sessions, and session 
 attributes.  It logs
   context creation but not destruction.  Here's some sample
  catalina.log

RE: sessionS info persistence when restart Tomcat

[Shapira, Yoav]

Hi,
Are you running Tomcat as a windows service?  If so there's an open
issue with it not calling certain destroy methods on shutdown.

Yoav Shapira http://www.yoavshapira.com


-Original Message-
From: Ben Souther [mailto:[EMAIL PROTECTED]
Sent: Thursday, November 04, 2004 9:22 PM
To: Tomcat Users List
Subject: RE: sessionS info persistence when restart Tomcat

SessionDestroyed shouldn't be called when tomcat shuts down. Otherwise,
the session wouldn't be valid when it starts up.  I just tested with a
clean install of 5.0.29 with a similar listener to the one you
describe.
SessionDestroyed was not called when I stopped TC but the sessions were
still valid when I started it up.  I can give you the war file if you
like.

Do all of the attributes that you're adding to your session implement
Serializable?

 C:\jakarta-tomcat-5.0.28\work\Catalina\localhost\ao\SESSIONS.ser (The
system cannot find the path specified)
Does tomcat have sufficient permissions to write to the work directory?

How are you stopping Tomcat?



On Thu, 2004-11-04 at 20:15, Steve Kirk wrote:
 Following Yoav's earlier comments I've implemented a basic class
 SessionLogger that implements HttpSessionListener,
 HttpSessionActivationListener, HttpSessionAttributeListener,
 ServletContextListener.  It just writes amessages to stdout using
 System.out.println() to log when each event fires, including each of
the
 interface events plus instantiation and finalization of SessionLogger
 itself.  I've configured it in web.xml:

 listener
  listener-classcore.servlet.SessionLogger/listener-class
 /listener

 SessionLogger logs its own presence OK when I instantiate it, and
happily
 logs events as expected on sessions, and session attributes.  It logs
 context creation but not destruction.  Here's some sample
catalina.log
lines
 for starting TC, logging in, logging out, logging in again:

 2004-11-05 00:56:50 StandardContext[/ao]*** SERVLET CONTEXT:
initialized
 2004-11-05 00:58:08 StandardContext[/ao]*** SESSION EVENT:
sessionCreated,
 [EMAIL PROTECTED]
 2004-11-05 00:58:23 StandardContext[/ao]*** SESSION ATTRIBUTE EVENT:
 attributeAdded, LOGGED_IN_USER, [ID=1]
 2004-11-05 00:58:30 StandardContext[/ao]*** SESSION ATTRIBUTE EVENT:
 attributeRemoved, LOGGED_IN_USER, [ID=1]
 2004-11-05 00:58:30 StandardContext[/ao]*** SESSION EVENT:
sessionDestroyed,
 [EMAIL PROTECTED]
 2004-11-05 00:58:30 StandardContext[/ao]*** SESSION EVENT:
sessionCreated,
 [EMAIL PROTECTED]
 2004-11-05 00:58:34 StandardContext[/ao]*** SESSION ATTRIBUTE EVENT:
 attributeAdded, LOGGED_IN_USER, [ID=1]

 However if I then stop TC, I get nothing logged at all after the
 attributeAdded event.  The log just shows this as the last line:

 05-Nov-2004 00:03:57 org.apache.coyote.http11.Http11Protocol pause
INFO:
 Pausing Coyote HTTP/1.1 on http-80

 and there are no loglines to indicate that the
 SessionLogger#sessionDestroyed, SessionLogger#contextDestroyed or
 SessionLogger#finalize methods were called.

 So it looks like sessions are working, but something is not working
when
TC
 stops, and I suspect that this is why my sessions don't persist over
 restarts.  I've read the docs and how-tos that I can find, plus
googled
 forum stuff on the web.  Does anyone have any insights please?

 PS the above applies whether or not I explicitly add a Manager to my
context
 config.  Note that the standard config files for 5.0.28 do not
explictly
 include a Manager, but the docs say that A Manager element MAY be
nested
 inside a Context component. If it is not included, a default Manager
 configuration will be created automatically.  I tried adding a
Manager
to
 my context as follows just in case following Yoav's earlier comments:
 Manager className=org.apache.catalina.session.StandardManager
 distributable=false debug=4 pathname=SESSIONS.ser /
 but this made no difference to the behaviour described above.

 Another weird thing: if I trigger a webapp reload by rebuilding my
warfile
 while TC is running, TC complains about the absence of SESSIONS.ser -
it
 appears to be trying to persist sessions to the file - which it does
not
try
 to do when I stop TC.  The log message is:

 05-Nov-2004 00:23:26 org.apache.catalina.session.StandardManager
doUnload
 SEVERE: IOException while saving persisted sessions:
 java.io.FileNotFoundException:
 C:\jakarta-tomcat-5.0.28\work\Catalina\localhost\ao\SESSIONS.ser (The
system
 cannot find the path specified)

 The file does not exist so the message sort of makes sense, except
that
this
 does not happen if I stop and then start TC again - only if a reload
is
 triggered when I rebuild my warfile.

  -Original Message-
  From: Shapira, Yoav [mailto:[EMAIL PROTECTED]
  Sent: Thursday 04 November 2004 16:09
  To: Tomcat Users List
  Subject: RE: sessionS info persistence when restart Tomcat
 
 
 
  Hi,
 
  I had always thought all sessions were lost when the server
restarts.
  In
  fact I just tried it and confirmed that (5.0.28).  Are we
  maybe

RE: sessionS info persistence when restart Tomcat

[Steve Kirk]

 to the file - 
 which it does not try
  to do when I stop TC.  The log message is:
  
  05-Nov-2004 00:23:26 
 org.apache.catalina.session.StandardManager doUnload
  SEVERE: IOException while saving persisted sessions:
  java.io.FileNotFoundException:
  
 C:\jakarta-tomcat-5.0.28\work\Catalina\localhost\ao\SESSIONS.s
 er (The system
  cannot find the path specified)
  
  The file does not exist so the message sort of makes sense, 
 except that this
  does not happen if I stop and then start TC again - only if 
 a reload is
  triggered when I rebuild my warfile.
  
   -Original Message-
   From: Shapira, Yoav [mailto:[EMAIL PROTECTED] 
   Sent: Thursday 04 November 2004 16:09
   To: Tomcat Users List
   Subject: RE: sessionS info persistence when restart Tomcat
   
   
   
   Hi,
   
   I had always thought all sessions were lost when the 
 server restarts.
   In
   fact I just tried it and confirmed that (5.0.28).  Are we 
   maybe talking
   about 2 different things?
   
   I think we're talking about the same thing.  Sessions are 
   supposed to be
   persisted by default.
   
   I have nonstandard config (a very sparse server.xml, no explicit
   Manager
   
   You need a Manager.  When I said by default I mean out 
 of the box,
   i.e. with the default server.xml, which has such a Manager IIRC.
   
   Is this the manager config ref you were talking about?
   
 http://jakarta.apache.org/tomcat/tomcat-5.0-doc/config/manager.html
   
   Yeah.
   
   I just read through it.  If I've understood correctly, because my
   Manager
   is
   not explicitly configured, 
   
   There's a difference between not explicitly configured and 
   not declared
   at all.
   
   One way to test this is with an
   HttpSessionListener/HttpSessionActivationListener (one 
 listener can
   implement both interfaces and thereby capture all four 
   relevant events).
   It's trivial to write one that just prints out information 
   when sessions
   are created, destroyed, passivated, and activated.
   
   Yoav



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

RE: sessionS info persistence when restart Tomcat

[Ben Souther]

On Fri, 2004-11-05 at 08:29, Shapira, Yoav wrote:
 Hi,
 Are you running Tomcat as a windows service?  If so there's an open
 issue with it not calling certain destroy methods on shutdown.
 
 Yoav Shapira http://www.yoavshapira.com
I believe that issue was with contextDestroyed not being called and was
tested under 5.0.8 and 5.5.x and working.







  
 
 -Original Message-
 From: Ben Souther [mailto:[EMAIL PROTECTED]
 Sent: Thursday, November 04, 2004 9:22 PM
 To: Tomcat Users List
 Subject: RE: sessionS info persistence when restart Tomcat
 
 SessionDestroyed shouldn't be called when tomcat shuts down. Otherwise,
 the session wouldn't be valid when it starts up.  I just tested with a
 clean install of 5.0.29 with a similar listener to the one you
 describe.
 SessionDestroyed was not called when I stopped TC but the sessions were
 still valid when I started it up.  I can give you the war file if you
 like.
 
 Do all of the attributes that you're adding to your session implement
 Serializable?
 
  C:\jakarta-tomcat-5.0.28\work\Catalina\localhost\ao\SESSIONS.ser (The
 system cannot find the path specified)
 Does tomcat have sufficient permissions to write to the work directory?
 
 How are you stopping Tomcat?
 
 
 
 On Thu, 2004-11-04 at 20:15, Steve Kirk wrote:
  Following Yoav's earlier comments I've implemented a basic class
  SessionLogger that implements HttpSessionListener,
  HttpSessionActivationListener, HttpSessionAttributeListener,
  ServletContextListener.  It just writes amessages to stdout using
  System.out.println() to log when each event fires, including each of
 the
  interface events plus instantiation and finalization of SessionLogger
  itself.  I've configured it in web.xml:
 
  listener
 listener-classcore.servlet.SessionLogger/listener-class
  /listener
 
  SessionLogger logs its own presence OK when I instantiate it, and
 happily
  logs events as expected on sessions, and session attributes.  It logs
  context creation but not destruction.  Here's some sample
 catalina.log
 lines
  for starting TC, logging in, logging out, logging in again:
 
  2004-11-05 00:56:50 StandardContext[/ao]*** SERVLET CONTEXT:
 initialized
  2004-11-05 00:58:08 StandardContext[/ao]*** SESSION EVENT:
 sessionCreated,
  [EMAIL PROTECTED]
  2004-11-05 00:58:23 StandardContext[/ao]*** SESSION ATTRIBUTE EVENT:
  attributeAdded, LOGGED_IN_USER, [ID=1]
  2004-11-05 00:58:30 StandardContext[/ao]*** SESSION ATTRIBUTE EVENT:
  attributeRemoved, LOGGED_IN_USER, [ID=1]
  2004-11-05 00:58:30 StandardContext[/ao]*** SESSION EVENT:
 sessionDestroyed,
  [EMAIL PROTECTED]
  2004-11-05 00:58:30 StandardContext[/ao]*** SESSION EVENT:
 sessionCreated,
  [EMAIL PROTECTED]
  2004-11-05 00:58:34 StandardContext[/ao]*** SESSION ATTRIBUTE EVENT:
  attributeAdded, LOGGED_IN_USER, [ID=1]
 
  However if I then stop TC, I get nothing logged at all after the
  attributeAdded event.  The log just shows this as the last line:
 
  05-Nov-2004 00:03:57 org.apache.coyote.http11.Http11Protocol pause
 INFO:
  Pausing Coyote HTTP/1.1 on http-80
 
  and there are no loglines to indicate that the
  SessionLogger#sessionDestroyed, SessionLogger#contextDestroyed or
  SessionLogger#finalize methods were called.
 
  So it looks like sessions are working, but something is not working
 when
 TC
  stops, and I suspect that this is why my sessions don't persist over
  restarts.  I've read the docs and how-tos that I can find, plus
 googled
  forum stuff on the web.  Does anyone have any insights please?
 
  PS the above applies whether or not I explicitly add a Manager to my
 context
  config.  Note that the standard config files for 5.0.28 do not
 explictly
  include a Manager, but the docs say that A Manager element MAY be
 nested
  inside a Context component. If it is not included, a default Manager
  configuration will be created automatically.  I tried adding a
 Manager
 to
  my context as follows just in case following Yoav's earlier comments:
  Manager className=org.apache.catalina.session.StandardManager
  distributable=false debug=4 pathname=SESSIONS.ser /
  but this made no difference to the behaviour described above.
 
  Another weird thing: if I trigger a webapp reload by rebuilding my
 warfile
  while TC is running, TC complains about the absence of SESSIONS.ser -
 it
  appears to be trying to persist sessions to the file - which it does
 not
 try
  to do when I stop TC.  The log message is:
 
  05-Nov-2004 00:23:26 org.apache.catalina.session.StandardManager
 doUnload
  SEVERE: IOException while saving persisted sessions:
  java.io.FileNotFoundException:
  C:\jakarta-tomcat-5.0.28\work\Catalina\localhost\ao\SESSIONS.ser (The
 system
  cannot find the path specified)
 
  The file does not exist so the message sort of makes sense, except
 that
 this
  does not happen if I stop and then start TC again - only if a reload
 is
  triggered when I rebuild my warfile.
 
   -Original Message-
   From: Shapira, Yoav [mailto:[EMAIL

RE: sessionS info persistence when restart Tomcat

[Steve Kirk]

OK well to be clear yes I'm running 5.0.28 on JDK 1.4.2_05 on Win2k SP4

 -Original Message-
 From: Ben Souther [mailto:[EMAIL PROTECTED] 
 Sent: Friday 05 November 2004 14:52
 To: Tomcat Users List
 Subject: RE: sessionS info persistence when restart Tomcat
 
 
 On Fri, 2004-11-05 at 08:29, Shapira, Yoav wrote:
  Hi,
  Are you running Tomcat as a windows service?  If so there's an open
  issue with it not calling certain destroy methods on shutdown.
  
  Yoav Shapira http://www.yoavshapira.com
 I believe that issue was with contextDestroyed not being 
 called and was
 tested under 5.0.8 and 5.5.x and working.
  
  
  -Original Message-
  From: Ben Souther [mailto:[EMAIL PROTECTED]
  Sent: Thursday, November 04, 2004 9:22 PM
  To: Tomcat Users List
  Subject: RE: sessionS info persistence when restart Tomcat
  
  SessionDestroyed shouldn't be called when tomcat shuts 
 down. Otherwise,
  the session wouldn't be valid when it starts up.  I just 
 tested with a
  clean install of 5.0.29 with a similar listener to the one you
  describe.
  SessionDestroyed was not called when I stopped TC but the 
 sessions were
  still valid when I started it up.  I can give you the war 
 file if you
  like.
  
  Do all of the attributes that you're adding to your 
 session implement
  Serializable?
  
   
 C:\jakarta-tomcat-5.0.28\work\Catalina\localhost\ao\SESSIONS.ser (The
  system cannot find the path specified)
  Does tomcat have sufficient permissions to write to the 
 work directory?
  
  How are you stopping Tomcat?
  
  
  
  On Thu, 2004-11-04 at 20:15, Steve Kirk wrote:
   Following Yoav's earlier comments I've implemented a basic class
   SessionLogger that implements HttpSessionListener,
   HttpSessionActivationListener, HttpSessionAttributeListener,
   ServletContextListener.  It just writes amessages to stdout using
   System.out.println() to log when each event fires, 
 including each of
  the
   interface events plus instantiation and finalization of 
 SessionLogger
   itself.  I've configured it in web.xml:
  
   listener
listener-classcore.servlet.SessionLogger/listener-class
   /listener
  
   SessionLogger logs its own presence OK when I instantiate it, and
  happily
   logs events as expected on sessions, and session 
 attributes.  It logs
   context creation but not destruction.  Here's some sample
  catalina.log
  lines
   for starting TC, logging in, logging out, logging in again:
  
   2004-11-05 00:56:50 StandardContext[/ao]*** SERVLET CONTEXT:
  initialized
   2004-11-05 00:58:08 StandardContext[/ao]*** SESSION EVENT:
  sessionCreated,
   [EMAIL PROTECTED]
   2004-11-05 00:58:23 StandardContext[/ao]*** SESSION 
 ATTRIBUTE EVENT:
   attributeAdded, LOGGED_IN_USER, [ID=1]
   2004-11-05 00:58:30 StandardContext[/ao]*** SESSION 
 ATTRIBUTE EVENT:
   attributeRemoved, LOGGED_IN_USER, [ID=1]
   2004-11-05 00:58:30 StandardContext[/ao]*** SESSION EVENT:
  sessionDestroyed,
   [EMAIL PROTECTED]
   2004-11-05 00:58:30 StandardContext[/ao]*** SESSION EVENT:
  sessionCreated,
   [EMAIL PROTECTED]
   2004-11-05 00:58:34 StandardContext[/ao]*** SESSION 
 ATTRIBUTE EVENT:
   attributeAdded, LOGGED_IN_USER, [ID=1]
  
   However if I then stop TC, I get nothing logged at all after the
   attributeAdded event.  The log just shows this as the 
 last line:
  
   05-Nov-2004 00:03:57 
 org.apache.coyote.http11.Http11Protocol pause
  INFO:
   Pausing Coyote HTTP/1.1 on http-80
  
   and there are no loglines to indicate that the
   SessionLogger#sessionDestroyed, SessionLogger#contextDestroyed or
   SessionLogger#finalize methods were called.
  
   So it looks like sessions are working, but something is 
 not working
  when
  TC
   stops, and I suspect that this is why my sessions don't 
 persist over
   restarts.  I've read the docs and how-tos that I can find, plus
  googled
   forum stuff on the web.  Does anyone have any insights please?
  
   PS the above applies whether or not I explicitly add a 
 Manager to my
  context
   config.  Note that the standard config files for 5.0.28 do not
  explictly
   include a Manager, but the docs say that A Manager 
 element MAY be
  nested
   inside a Context component. If it is not included, a 
 default Manager
   configuration will be created automatically.  I tried adding a
  Manager
  to
   my context as follows just in case following Yoav's 
 earlier comments:
   Manager className=org.apache.catalina.session.StandardManager
   distributable=false debug=4 pathname=SESSIONS.ser /
   but this made no difference to the behaviour described above.
  
   Another weird thing: if I trigger a webapp reload by 
 rebuilding my
  warfile
   while TC is running, TC complains about the absence of 
 SESSIONS.ser -
  it
   appears to be trying to persist sessions to the file - 
 which it does
  not
  try
   to do when I stop TC.  The log message is:
  
   05-Nov-2004 00:23:26 org.apache.catalina.session.StandardManager
  doUnload
   SEVERE: IOException while saving

RE: sessionS info persistence when restart Tomcat

[Ben Souther]

On Fri, 2004-11-05 at 09:06, Steve Kirk wrote:
  SessionDestroyed shouldn't be called when tomcat shuts down. 
 
 good point.  doh!  but if I've understood correctly, shouldn't other methods
 of my SessionLogger be called?  namely sessionWillPassivate,
 contextDestroyed (and possibly finalize although I'm not 100% confident of
 that).
contextDestroyed does get called when you shut down tomcat. I don't know
about sessionWillPassivate.

 
  I just tested with a
  clean install of 5.0.29 with a similar listener to the one 
  you describe.
  SessionDestroyed was not called when I stopped TC but the 
  sessions were
  still valid when I started it up.  I can give you the war file if you
  like.
 
 yes please.  email it to me off list if you prefer.

You can grab it here:
http://www.souther.us/sessionTest.war

I ran it in a clean install of TC5.0.29.
There are two jsps and a sessionListener.
test.jsp shows you the current sessionID.
kill.jsp invalidates the session.
The session listener prints to stdout (catalina.out)
when a session is created or destroyed.

I was able to stop and restart TC and maintain the same session.
sessionDestroyed was not called.

You could easily add to it to test for sessionWillPassivate().





 
  Do all of the attributes that you're adding to your session implement
  Serializable?
 
 I did spot that issue late on just before my last post.  So I checked and
 only one object is ever stored in the session - a User class of my own.
 Its fields are all of type String, java.sql.Timestamp or int.  I added
 implements Serializable to it (I think this is all that was required?) but
 this made no difference.  Also, I have tried stopping TC when a session has
 been created but *no* attributes have been added to it, and the problem is
 the same.
 
 In any case though, if serialisation was the problem, shouldn't I see some
 kind of error message from TC along the lines that it cannot serialise an
 object in a session?  Also I can't work out why it only complains that it
 can't find SESSIONS.ser when it reloads the webapp?
 
If your object (or any of the objects contained within it) are not
serializable) tomcat will quietly not save it.

try creating a real simple object that implements Serializable and see
if it survives a restart.

-Ben




-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

RE: sessionS info persistence when restart Tomcat

[Steve Kirk]

Thanks Ben, have looked at your war, and my test code covers the same as
yours plus some of the other Listener events.  The sessionCreated and
sessionDestroyed events work fine on my code (5.0.28).  The problem is that
the other events I mentioned are not called - e.g. contextDestroyed.

 If your object (or any of the objects contained within it) are not
 serializable) tomcat will quietly not save it.

ok that's interesting and perhaps a little surprising given that the docs
say that they MUST be.  I've also tried adding the distributable attribute
to the webapp as indicated here
http://jakarta.apache.org/tomcat/tomcat-5.0-doc/config/manager.html#Restart%
20Persistence 
to see if that causes stricter behaviour (e.g. throwing an exception when TC
tries to serialize session objects), but this appears to make no difference
in my situation.

 try creating a real simple object that implements Serializable and see
 if it survives a restart.

In effect I have already done that by restarting TC, then browsing webapp
pages as a user that does not log in.  In this case I do not assign any
objects to the session (I have checked this using session.getAttributeNames
in my SessionLogger to check that there are none).  Even in this case TC
does not serialize to SESSIONS.ser on shutdown.  So I don't think that the
problem is serialisability?

Also, still can't work out why SESSIONS.ser is only accessed when a new
warfile causes a reload and not otherwise.

 -Original Message-
 From: Ben Souther [mailto:[EMAIL PROTECTED] 
 Sent: Friday 05 November 2004 15:08
 To: Tomcat Users List
 Subject: RE: sessionS info persistence when restart Tomcat
 
 
 On Fri, 2004-11-05 at 09:06, Steve Kirk wrote:
   SessionDestroyed shouldn't be called when tomcat shuts down. 
  
  good point.  doh!  but if I've understood correctly, 
 shouldn't other methods
  of my SessionLogger be called?  namely sessionWillPassivate,
  contextDestroyed (and possibly finalize although I'm not 
 100% confident of
  that).
 contextDestroyed does get called when you shut down tomcat. I 
 don't know
 about sessionWillPassivate.
 
  
   I just tested with a
   clean install of 5.0.29 with a similar listener to the one 
   you describe.
   SessionDestroyed was not called when I stopped TC but the 
   sessions were
   still valid when I started it up.  I can give you the war 
 file if you
   like.
  
  yes please.  email it to me off list if you prefer.
 
 You can grab it here:
 http://www.souther.us/sessionTest.war
 
 I ran it in a clean install of TC5.0.29.
 There are two jsps and a sessionListener.
 test.jsp shows you the current sessionID.
 kill.jsp invalidates the session.
 The session listener prints to stdout (catalina.out)
 when a session is created or destroyed.
 
 I was able to stop and restart TC and maintain the same session.
 sessionDestroyed was not called.
 
 You could easily add to it to test for sessionWillPassivate().
 
 
 
 
 
  
   Do all of the attributes that you're adding to your 
 session implement
   Serializable?
  
  I did spot that issue late on just before my last post.  So 
 I checked and
  only one object is ever stored in the session - a User 
 class of my own.
  Its fields are all of type String, java.sql.Timestamp or 
 int.  I added
  implements Serializable to it (I think this is all that 
 was required?) but
  this made no difference.  Also, I have tried stopping TC 
 when a session has
  been created but *no* attributes have been added to it, and 
 the problem is
  the same.
  
  In any case though, if serialisation was the problem, 
 shouldn't I see some
  kind of error message from TC along the lines that it 
 cannot serialise an
  object in a session?  Also I can't work out why it only 
 complains that it
  can't find SESSIONS.ser when it reloads the webapp?
  
 If your object (or any of the objects contained within it) are not
 serializable) tomcat will quietly not save it.
 
 try creating a real simple object that implements Serializable and see
 if it survives a restart.
 
 -Ben
 
 
 
 
 -
 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]

RE: sessionS info persistence when restart Tomcat

[Ben Souther]

Have you tried any of this on a fresh install of Tomcat?
I think you mentioned that you have made changes to the Persistance
Manaager in server.xml.

Try downloading and installing a fresh instance and run the test again.
There is a similar test war file (attachment) that looks tests the
contextCreated/Destroyed methods here:
http://issues.apache.org/bugzilla/show_bug.cgi?id=29521

For what it's worth. Serialization of sessions is working for me with
5.0.28 running as an NT Service on windows.

-Ben

On Fri, 2004-11-05 at 11:20, Steve Kirk wrote:
 Thanks Ben, have looked at your war, and my test code covers the same as
 yours plus some of the other Listener events.  The sessionCreated and
 sessionDestroyed events work fine on my code (5.0.28).  The problem is that
 the other events I mentioned are not called - e.g. contextDestroyed.
 
  If your object (or any of the objects contained within it) are not
  serializable) tomcat will quietly not save it.
 
 ok that's interesting and perhaps a little surprising given that the docs
 say that they MUST be.  I've also tried adding the distributable attribute
 to the webapp as indicated here
 http://jakarta.apache.org/tomcat/tomcat-5.0-doc/config/manager.html#Restart%
 20Persistence 
 to see if that causes stricter behaviour (e.g. throwing an exception when TC
 tries to serialize session objects), but this appears to make no difference
 in my situation.
 
  try creating a real simple object that implements Serializable and see
  if it survives a restart.
 
 In effect I have already done that by restarting TC, then browsing webapp
 pages as a user that does not log in.  In this case I do not assign any
 objects to the session (I have checked this using session.getAttributeNames
 in my SessionLogger to check that there are none).  Even in this case TC
 does not serialize to SESSIONS.ser on shutdown.  So I don't think that the
 problem is serialisability?
 
 Also, still can't work out why SESSIONS.ser is only accessed when a new
 warfile causes a reload and not otherwise.
 
  -Original Message-
  From: Ben Souther [mailto:[EMAIL PROTECTED] 
  Sent: Friday 05 November 2004 15:08
  To: Tomcat Users List
  Subject: RE: sessionS info persistence when restart Tomcat
  
  
  On Fri, 2004-11-05 at 09:06, Steve Kirk wrote:
SessionDestroyed shouldn't be called when tomcat shuts down. 
   
   good point.  doh!  but if I've understood correctly, 
  shouldn't other methods
   of my SessionLogger be called?  namely sessionWillPassivate,
   contextDestroyed (and possibly finalize although I'm not 
  100% confident of
   that).
  contextDestroyed does get called when you shut down tomcat. I 
  don't know
  about sessionWillPassivate.
  
   
I just tested with a
clean install of 5.0.29 with a similar listener to the one 
you describe.
SessionDestroyed was not called when I stopped TC but the 
sessions were
still valid when I started it up.  I can give you the war 
  file if you
like.
   
   yes please.  email it to me off list if you prefer.
  
  You can grab it here:
  http://www.souther.us/sessionTest.war
  
  I ran it in a clean install of TC5.0.29.
  There are two jsps and a sessionListener.
  test.jsp shows you the current sessionID.
  kill.jsp invalidates the session.
  The session listener prints to stdout (catalina.out)
  when a session is created or destroyed.
  
  I was able to stop and restart TC and maintain the same session.
  sessionDestroyed was not called.
  
  You could easily add to it to test for sessionWillPassivate().
  
  
  
  
  
   
Do all of the attributes that you're adding to your 
  session implement
Serializable?
   
   I did spot that issue late on just before my last post.  So 
  I checked and
   only one object is ever stored in the session - a User 
  class of my own.
   Its fields are all of type String, java.sql.Timestamp or 
  int.  I added
   implements Serializable to it (I think this is all that 
  was required?) but
   this made no difference.  Also, I have tried stopping TC 
  when a session has
   been created but *no* attributes have been added to it, and 
  the problem is
   the same.
   
   In any case though, if serialisation was the problem, 
  shouldn't I see some
   kind of error message from TC along the lines that it 
  cannot serialise an
   object in a session?  Also I can't work out why it only 
  complains that it
   can't find SESSIONS.ser when it reloads the webapp?
   
  If your object (or any of the objects contained within it) are not
  serializable) tomcat will quietly not save it.
  
  try creating a real simple object that implements Serializable and see
  if it survives a restart.
  
  -Ben
  
  
  
  
  -
  To unsubscribe, e-mail: [EMAIL PROTECTED]
  For additional commands, e-mail: [EMAIL PROTECTED]
  
  
 
 
 
 -
 To unsubscribe, e

RE: sessionS info persistence when restart Tomcat

[Steve Kirk]

 -Original Message-
 From: Ben Souther [mailto:[EMAIL PROTECTED] 

 Have you tried any of this on a fresh install of Tomcat?

No, I last installed fresh a couple of weeks back to upgrade from .27 ; I
deleted the whole CATALINA_HOME dir first.  I then replaced conf/server.xml
and conf/web.xml, and installed my warfiles.

 I think you mentioned that you have made changes to the Persistance
 Manaager in server.xml.

sort of.  I have modified server.xml, although having said that, there is no
Manager by default in server.xml, persistent or not, as far as I can tell.

My server.xml is very sparse:
Server
Service name=Catalina-AO-Service
Connector port=80
acceptCount=100 
allowTrace=false 
connectionTimeout=2 
disableUploadTimeout=true 
enableLookups=false 
maxPostSize=10 
maxSpareThreads=75 
maxThreads=150 
minSpareThreads=25 
redirectPort=443 
scheme=http 
secure=false 
 /
Engine name=Catalina-Engine defaultHost=localhost
Host name=localhost appBase=webapps
Logger
className=org.apache.catalina.logger.FileLogger timestamp=true/
/Host
/Engine
/Service
/Server


 Try downloading and installing a fresh instance and run the 
 test again.
 There is a similar test war file (attachment) that looks tests the
 contextCreated/Destroyed methods here:
 http://issues.apache.org/bugzilla/show_bug.cgi?id=29521

OK, will do next week but out of time for that today.

 For what it's worth. Serialization of sessions is working for me with
 5.0.28 running as an NT Service on windows.

aha. so it looks like it's something I screwed up ;)

out of interest, does contextDestroyed work on that platform?

 -Ben
 
 On Fri, 2004-11-05 at 11:20, Steve Kirk wrote:
  Thanks Ben, have looked at your war, and my test code 
 covers the same as
  yours plus some of the other Listener events.  The 
 sessionCreated and
  sessionDestroyed events work fine on my code (5.0.28).  The 
 problem is that
  the other events I mentioned are not called - e.g. contextDestroyed.
  
   If your object (or any of the objects contained within it) are not
   serializable) tomcat will quietly not save it.
  
  ok that's interesting and perhaps a little surprising given 
 that the docs
  say that they MUST be.  I've also tried adding the 
 distributable attribute
  to the webapp as indicated here
  
 http://jakarta.apache.org/tomcat/tomcat-5.0-doc/config/manager
 .html#Restart%
  20Persistence 
  to see if that causes stricter behaviour (e.g. throwing an 
 exception when TC
  tries to serialize session objects), but this appears to 
 make no difference
  in my situation.
  
   try creating a real simple object that implements 
 Serializable and see
   if it survives a restart.
  
  In effect I have already done that by restarting TC, then 
 browsing webapp
  pages as a user that does not log in.  In this case I do 
 not assign any
  objects to the session (I have checked this using 
 session.getAttributeNames
  in my SessionLogger to check that there are none).  Even in 
 this case TC
  does not serialize to SESSIONS.ser on shutdown.  So I don't 
 think that the
  problem is serialisability?
  
  Also, still can't work out why SESSIONS.ser is only 
 accessed when a new
  warfile causes a reload and not otherwise.
  
   -Original Message-
   From: Ben Souther [mailto:[EMAIL PROTECTED] 
   Sent: Friday 05 November 2004 15:08
   To: Tomcat Users List
   Subject: RE: sessionS info persistence when restart Tomcat
   
   
   On Fri, 2004-11-05 at 09:06, Steve Kirk wrote:
 SessionDestroyed shouldn't be called when tomcat shuts down. 

good point.  doh!  but if I've understood correctly, 
   shouldn't other methods
of my SessionLogger be called?  namely sessionWillPassivate,
contextDestroyed (and possibly finalize although I'm not 
   100% confident of
that).
   contextDestroyed does get called when you shut down tomcat. I 
   don't know
   about sessionWillPassivate.
   

 I just tested with a
 clean install of 5.0.29 with a similar listener to the one 
 you describe.
 SessionDestroyed was not called when I stopped TC but the 
 sessions were
 still valid when I started it up.  I can give you the war 
   file if you
 like.

yes please.  email it to me off list if you prefer.
   
   You can grab it here:
   http://www.souther.us/sessionTest.war
   
   I ran it in a clean install of TC5.0.29.
   There are two jsps and a sessionListener.
   test.jsp shows you the current sessionID.
   kill.jsp invalidates the session.
   The session listener prints

RE: sessionS info persistence when restart Tomcat

[Ben Souther]

 aha. so it looks like it's something I screwed up ;)
 
I don't know. I just know that, in my case, the object that I put into
session survives restarts. The easiest way to test things like this, for
me, is to write a small test app and run it on a fresh install of
Tomcat. If it works there then I start comparing with my app.


 out of interest, does contextDestroyed work on that platform?
 
It does, I tested on win2k as a service, from the start menu items, and
with the .bat scripts.  I also tested on FC2 and RH73. In all cases
contextDestroyed was called.

-Ben




-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

RE: sessionS info persistence when restart Tomcat

[Mark]

The object stored in the session must implement serializable 
interface, right? Or any Java Class object can be stored in the
session and persistence manager will take care how to save and
restore it?

--- Ben Souther [EMAIL PROTECTED] wrote:

  aha. so it looks like it's something I screwed up ;)
  
 I don't know. I just know that, in my case, the object that I put
 into
 session survives restarts. The easiest way to test things like
 this, for
 me, is to write a small test app and run it on a fresh install of
 Tomcat. If it works there then I start comparing with my app.
 
 
  out of interest, does contextDestroyed work on that platform?
  
 It does, I tested on win2k as a service, from the start menu items,
 and
 with the .bat scripts.  I also tested on FC2 and RH73. In all cases
 contextDestroyed was called.
 
 -Ben
 
 
 
 

-
 To unsubscribe, e-mail: [EMAIL PROTECTED]
 For additional commands, e-mail:
 [EMAIL PROTECTED]
 
 




__ 
Do you Yahoo!? 
Check out the new Yahoo! Front Page. 
www.yahoo.com 
 


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

RE: sessionS info persistence when restart Tomcat

[Ben Souther]

On Fri, 2004-11-05 at 14:53, Mark wrote:
 The object stored in the session must implement serializable 
 interface, right? Or any Java Class object can be stored in the
 session and persistence manager will take care how to save and
 restore it?
It must implement Serializable and any nested objects must implement
Serializable.


 
 --- Ben Souther [EMAIL PROTECTED] wrote:
 
   aha. so it looks like it's something I screwed up ;)
   
  I don't know. I just know that, in my case, the object that I put
  into
  session survives restarts. The easiest way to test things like
  this, for
  me, is to write a small test app and run it on a fresh install of
  Tomcat. If it works there then I start comparing with my app.
  
  
   out of interest, does contextDestroyed work on that platform?
   
  It does, I tested on win2k as a service, from the start menu items,
  and
  with the .bat scripts.  I also tested on FC2 and RH73. In all cases
  contextDestroyed was called.
  
  -Ben
  
  
  
  
 
 -
  To unsubscribe, e-mail: [EMAIL PROTECTED]
  For additional commands, e-mail:
  [EMAIL PROTECTED]
  
  
 
 
 
   
 __ 
 Do you Yahoo!? 
 Check out the new Yahoo! Front Page. 
 www.yahoo.com
 
 
 
 -
 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]

RE: sessionS info persistence when restart Tomcat

[Shapira, Yoav]

Hi,
Tomcat persists and reloads sessions on restart by default.  And the
default session timeout is 30 minutes.  So you shouldn't have to do
anything.

Check out the Manager configuration reference (not the Manager webapp)
for more details and settings you can modify in this area.

Yoav Shapira http://www.yoavshapira.com


-Original Message-
From: Mark [mailto:[EMAIL PROTECTED]
Sent: Thursday, November 04, 2004 10:04 AM
To: [EMAIL PROTECTED]
Subject: sessionS info persistence when restart Tomcat

Hi,

Is it possible to save sessions info, so when Tomcat restarts all
previously active sessions will be loaded.

I'm trying to prevent user's re-login when Tomcat goes down for short
period (5-15 minutes) of time.

Thanks,
Mark



__
Do you Yahoo!?
Check out the new Yahoo! Front Page.
www.yahoo.com



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]




This e-mail, including any attachments, is a confidential business communication, and 
may contain information that is confidential, proprietary and/or privileged.  This 
e-mail is intended only for the individual(s) to whom it is addressed, and may not be 
saved, copied, printed, disclosed or used by anyone else.  If you are not the(an) 
intended recipient, please immediately delete this e-mail from your computer system 
and notify the sender.  Thank you.


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

RE: sessionS info persistence when restart Tomcat

[Steve Kirk]

I had always thought all sessions were lost when the server restarts.  In
fact I just tried it and confirmed that (5.0.28).  Are we maybe talking
about 2 different things?

I have nonstandard config (a very sparse server.xml, no explicit Manager
configured in server/web/context xml), and I do not use TC
authentication/realms, I just use request.getSession(true) and rely on
cookies to track users.  After a restart, the webapp has lost track of users
that were tracked right up to the restart.

Is this the manager config ref you were talking about?
http://jakarta.apache.org/tomcat/tomcat-5.0-doc/config/manager.html 

I just read through it.  If I've understood correctly, because my Manager is
not explicitly configured, I have a default session manager implicitly.  I
stopped the server and looked for the serialised session file under /work
but just found the usual .java and .class files and one file called
tldCache.ser, no sessions.ser or anything that looks like a serialised
session file.

 -Original Message-
 From: Shapira, Yoav [mailto:[EMAIL PROTECTED] 
 Sent: Thursday 04 November 2004 15:07
 To: Tomcat Users List
 Subject: RE: sessionS info persistence when restart Tomcat
 
 
 
 Hi,
 Tomcat persists and reloads sessions on restart by default.  And the
 default session timeout is 30 minutes.  So you shouldn't have to do
 anything.
 
 Check out the Manager configuration reference (not the Manager webapp)
 for more details and settings you can modify in this area.
 
 Yoav Shapira http://www.yoavshapira.com
  
 
 -Original Message-
 From: Mark [mailto:[EMAIL PROTECTED]
 Sent: Thursday, November 04, 2004 10:04 AM
 To: [EMAIL PROTECTED]
 Subject: sessionS info persistence when restart Tomcat
 
 Hi,
 
 Is it possible to save sessions info, so when Tomcat restarts all
 previously active sessions will be loaded.
 
 I'm trying to prevent user's re-login when Tomcat goes down for short
 period (5-15 minutes) of time.
 
 Thanks,
 Mark
 
 
 
 __
 Do you Yahoo!?
 Check out the new Yahoo! Front Page.
 www.yahoo.com
 
 
 
 -
 To unsubscribe, e-mail: [EMAIL PROTECTED]
 For additional commands, e-mail: [EMAIL PROTECTED]
 
 
 
 
 This e-mail, including any attachments, is a confidential 
 business communication, and may contain information that is 
 confidential, proprietary and/or privileged.  This e-mail is 
 intended only for the individual(s) to whom it is addressed, 
 and may not be saved, copied, printed, disclosed or used by 
 anyone else.  If you are not the(an) intended recipient, 
 please immediately delete this e-mail from your computer 
 system and notify the sender.  Thank you.
 
 
 -
 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]

RE: sessionS info persistence when restart Tomcat

[Shapira, Yoav]

Hi,

I had always thought all sessions were lost when the server restarts.
In
fact I just tried it and confirmed that (5.0.28).  Are we maybe talking
about 2 different things?

I think we're talking about the same thing.  Sessions are supposed to be
persisted by default.

I have nonstandard config (a very sparse server.xml, no explicit
Manager

You need a Manager.  When I said by default I mean out of the box,
i.e. with the default server.xml, which has such a Manager IIRC.

Is this the manager config ref you were talking about?
http://jakarta.apache.org/tomcat/tomcat-5.0-doc/config/manager.html

Yeah.

I just read through it.  If I've understood correctly, because my
Manager
is
not explicitly configured,

There's a difference between not explicitly configured and not declared
at all.

One way to test this is with an
HttpSessionListener/HttpSessionActivationListener (one listener can
implement both interfaces and thereby capture all four relevant events).
It's trivial to write one that just prints out information when sessions
are created, destroyed, passivated, and activated.

Yoav



This e-mail, including any attachments, is a confidential business communication, and 
may contain information that is confidential, proprietary and/or privileged.  This 
e-mail is intended only for the individual(s) to whom it is addressed, and may not be 
saved, copied, printed, disclosed or used by anyone else.  If you are not the(an) 
intended recipient, please immediately delete this e-mail from your computer system 
and notify the sender.  Thank you.


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

RE: sessionS info persistence when restart Tomcat

[Mark]

Here some info I found:
http://jakarta.apache.org/tomcat/tomcat-5.0-doc/config/manager.html

but...:
--cut -
Persistent Manager Implementation

WARNING - Use of this Manager implementation has not been thoroughly
tested, and should be considered experimental! 

 end cut --

Can anybody confirm what is a status for Persistent Manager in Tomcat
5.0.X? is it stable, is it safe to use in production and if not what
are other options.

and here another link with detailed info on Persistent Manager:
http://www.devx.com/assets/download/6264.pdf

Mark.


--- Steve Kirk [EMAIL PROTECTED] wrote:

 I had always thought all sessions were lost when the server
 restarts.  In
 fact I just tried it and confirmed that (5.0.28).  Are we maybe
 talking
 about 2 different things?
 
 I have nonstandard config (a very sparse server.xml, no explicit
 Manager
 configured in server/web/context xml), and I do not use TC
 authentication/realms, I just use request.getSession(true) and rely
 on
 cookies to track users.  After a restart, the webapp has lost track
 of users
 that were tracked right up to the restart.
 
 Is this the manager config ref you were talking about?
 http://jakarta.apache.org/tomcat/tomcat-5.0-doc/config/manager.html
 
 
 I just read through it.  If I've understood correctly, because my
 Manager is
 not explicitly configured, I have a default session manager
 implicitly.  I
 stopped the server and looked for the serialised session file under
 /work
 but just found the usual .java and .class files and one file called
 tldCache.ser, no sessions.ser or anything that looks like a
 serialised
 session file.
 
  -Original Message-
  From: Shapira, Yoav [mailto:[EMAIL PROTECTED] 
  Sent: Thursday 04 November 2004 15:07
  To: Tomcat Users List
  Subject: RE: sessionS info persistence when restart Tomcat
  
  
  
  Hi,
  Tomcat persists and reloads sessions on restart by default.  And
 the
  default session timeout is 30 minutes.  So you shouldn't have to
 do
  anything.
  
  Check out the Manager configuration reference (not the Manager
 webapp)
  for more details and settings you can modify in this area.
  
  Yoav Shapira http://www.yoavshapira.com
   
  
  -Original Message-
  From: Mark [mailto:[EMAIL PROTECTED]
  Sent: Thursday, November 04, 2004 10:04 AM
  To: [EMAIL PROTECTED]
  Subject: sessionS info persistence when restart Tomcat
  
  Hi,
  
  Is it possible to save sessions info, so when Tomcat restarts
 all
  previously active sessions will be loaded.
  
  I'm trying to prevent user's re-login when Tomcat goes down for
 short
  period (5-15 minutes) of time.
  
  Thanks,
  Mark
  
  
  
  __
  Do you Yahoo!?
  Check out the new Yahoo! Front Page.
  www.yahoo.com
  
  
  
 

-
  To unsubscribe, e-mail:
 [EMAIL PROTECTED]
  For additional commands, e-mail:
 [EMAIL PROTECTED]
  
  
  
  
  This e-mail, including any attachments, is a confidential 
  business communication, and may contain information that is 
  confidential, proprietary and/or privileged.  This e-mail is 
  intended only for the individual(s) to whom it is addressed, 
  and may not be saved, copied, printed, disclosed or used by 
  anyone else.  If you are not the(an) intended recipient, 
  please immediately delete this e-mail from your computer 
  system and notify the sender.  Thank you.
  
  
 

-
  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]
 
 




__ 
Do you Yahoo!? 
Check out the new Yahoo! Front Page. 
www.yahoo.com 
 


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

RE: sessionS info persistence when restart Tomcat

[Shapira, Yoav]

Hi,
Hmm, I think that note is very old.  It was probably copied over from
Tomcat 4.  The PersistentManager hasn't had any bugs filed against it
for months at least  (and it's been around for years now) so it's
probably in good shape.

Yoav Shapira http://www.yoavshapira.com


-Original Message-
From: Mark [mailto:[EMAIL PROTECTED]
Sent: Thursday, November 04, 2004 2:14 PM
To: Tomcat Users List
Subject: RE: sessionS info persistence when restart Tomcat

Here some info I found:
http://jakarta.apache.org/tomcat/tomcat-5.0-doc/config/manager.html

but...:
--cut -
Persistent Manager Implementation

WARNING - Use of this Manager implementation has not been thoroughly
tested, and should be considered experimental!

 end cut --

Can anybody confirm what is a status for Persistent Manager in Tomcat
5.0.X? is it stable, is it safe to use in production and if not what
are other options.

and here another link with detailed info on Persistent Manager:
http://www.devx.com/assets/download/6264.pdf

Mark.


--- Steve Kirk [EMAIL PROTECTED] wrote:

 I had always thought all sessions were lost when the server
 restarts.  In
 fact I just tried it and confirmed that (5.0.28).  Are we maybe
 talking
 about 2 different things?

 I have nonstandard config (a very sparse server.xml, no explicit
 Manager
 configured in server/web/context xml), and I do not use TC
 authentication/realms, I just use request.getSession(true) and rely
 on
 cookies to track users.  After a restart, the webapp has lost track
 of users
 that were tracked right up to the restart.

 Is this the manager config ref you were talking about?
 http://jakarta.apache.org/tomcat/tomcat-5.0-doc/config/manager.html


 I just read through it.  If I've understood correctly, because my
 Manager is
 not explicitly configured, I have a default session manager
 implicitly.  I
 stopped the server and looked for the serialised session file under
 /work
 but just found the usual .java and .class files and one file called
 tldCache.ser, no sessions.ser or anything that looks like a
 serialised
 session file.

  -Original Message-
  From: Shapira, Yoav [mailto:[EMAIL PROTECTED]
  Sent: Thursday 04 November 2004 15:07
  To: Tomcat Users List
  Subject: RE: sessionS info persistence when restart Tomcat
 
 
 
  Hi,
  Tomcat persists and reloads sessions on restart by default.  And
 the
  default session timeout is 30 minutes.  So you shouldn't have to
 do
  anything.
 
  Check out the Manager configuration reference (not the Manager
 webapp)
  for more details and settings you can modify in this area.
 
  Yoav Shapira http://www.yoavshapira.com
 
 
  -Original Message-
  From: Mark [mailto:[EMAIL PROTECTED]
  Sent: Thursday, November 04, 2004 10:04 AM
  To: [EMAIL PROTECTED]
  Subject: sessionS info persistence when restart Tomcat
  
  Hi,
  
  Is it possible to save sessions info, so when Tomcat restarts
 all
  previously active sessions will be loaded.
  
  I'm trying to prevent user's re-login when Tomcat goes down for
 short
  period (5-15 minutes) of time.
  
  Thanks,
  Mark
  
  
  
  __
  Do you Yahoo!?
  Check out the new Yahoo! Front Page.
  www.yahoo.com
  
  
  
 

-
  To unsubscribe, e-mail:
 [EMAIL PROTECTED]
  For additional commands, e-mail:
 [EMAIL PROTECTED]
 
 
 
 
  This e-mail, including any attachments, is a confidential
  business communication, and may contain information that is
  confidential, proprietary and/or privileged.  This e-mail is
  intended only for the individual(s) to whom it is addressed,
  and may not be saved, copied, printed, disclosed or used by
  anyone else.  If you are not the(an) intended recipient,
  please immediately delete this e-mail from your computer
  system and notify the sender.  Thank you.
 
 
 

-
  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]






__
Do you Yahoo!?
Check out the new Yahoo! Front Page.
www.yahoo.com



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]




This e-mail, including any attachments, is a confidential business communication, and 
may contain information that is confidential, proprietary and/or privileged.  This 
e-mail is intended only for the individual(s) to whom it is addressed, and may not be 
saved, copied, printed, disclosed or used by anyone else.  If you are not the(an) 
intended recipient, please immediately delete this e-mail from your computer system 
and notify the sender.  Thank you

RE: sessionS info persistence when restart Tomcat

[Mark]

So it's a documentation bug then :-)

--- Shapira, Yoav [EMAIL PROTECTED] wrote:

 
 Hi,
 Hmm, I think that note is very old.  It was probably copied over
 from
 Tomcat 4.  The PersistentManager hasn't had any bugs filed against
 it
 for months at least  (and it's been around for years now) so it's
 probably in good shape.
 
 Yoav Shapira http://www.yoavshapira.com
 
 
 -Original Message-
 From: Mark [mailto:[EMAIL PROTECTED]
 Sent: Thursday, November 04, 2004 2:14 PM
 To: Tomcat Users List
 Subject: RE: sessionS info persistence when restart Tomcat
 
 Here some info I found:

http://jakarta.apache.org/tomcat/tomcat-5.0-doc/config/manager.html
 
 but...:
 --cut -
 Persistent Manager Implementation
 
 WARNING - Use of this Manager implementation has not been
 thoroughly
 tested, and should be considered experimental!
 
  end cut --
 
 Can anybody confirm what is a status for Persistent Manager in
 Tomcat
 5.0.X? is it stable, is it safe to use in production and if not
 what
 are other options.
 
 and here another link with detailed info on Persistent Manager:
 http://www.devx.com/assets/download/6264.pdf
 
 Mark.
 
 
 --- Steve Kirk [EMAIL PROTECTED] wrote:
 
  I had always thought all sessions were lost when the server
  restarts.  In
  fact I just tried it and confirmed that (5.0.28).  Are we maybe
  talking
  about 2 different things?
 
  I have nonstandard config (a very sparse server.xml, no explicit
  Manager
  configured in server/web/context xml), and I do not use TC
  authentication/realms, I just use request.getSession(true) and
 rely
  on
  cookies to track users.  After a restart, the webapp has lost
 track
  of users
  that were tracked right up to the restart.
 
  Is this the manager config ref you were talking about?
 
 http://jakarta.apache.org/tomcat/tomcat-5.0-doc/config/manager.html
 
 
  I just read through it.  If I've understood correctly, because
 my
  Manager is
  not explicitly configured, I have a default session manager
  implicitly.  I
  stopped the server and looked for the serialised session file
 under
  /work
  but just found the usual .java and .class files and one file
 called
  tldCache.ser, no sessions.ser or anything that looks like a
  serialised
  session file.
 
   -Original Message-
   From: Shapira, Yoav [mailto:[EMAIL PROTECTED]
   Sent: Thursday 04 November 2004 15:07
   To: Tomcat Users List
   Subject: RE: sessionS info persistence when restart Tomcat
  
  
  
   Hi,
   Tomcat persists and reloads sessions on restart by default. 
 And
  the
   default session timeout is 30 minutes.  So you shouldn't have
 to
  do
   anything.
  
   Check out the Manager configuration reference (not the Manager
  webapp)
   for more details and settings you can modify in this area.
  
   Yoav Shapira http://www.yoavshapira.com
  
  
   -Original Message-
   From: Mark [mailto:[EMAIL PROTECTED]
   Sent: Thursday, November 04, 2004 10:04 AM
   To: [EMAIL PROTECTED]
   Subject: sessionS info persistence when restart Tomcat
   
   Hi,
   
   Is it possible to save sessions info, so when Tomcat restarts
  all
   previously active sessions will be loaded.
   
   I'm trying to prevent user's re-login when Tomcat goes down
 for
  short
   period (5-15 minutes) of time.
   
   Thanks,
   Mark
   
   
   
   __
   Do you Yahoo!?
   Check out the new Yahoo! Front Page.
   www.yahoo.com
   
   
   
  
 

-
   To unsubscribe, e-mail:
  [EMAIL PROTECTED]
   For additional commands, e-mail:
  [EMAIL PROTECTED]
  
  
  
  
   This e-mail, including any attachments, is a confidential
   business communication, and may contain information that is
   confidential, proprietary and/or privileged.  This e-mail is
   intended only for the individual(s) to whom it is addressed,
   and may not be saved, copied, printed, disclosed or used by
   anyone else.  If you are not the(an) intended recipient,
   please immediately delete this e-mail from your computer
   system and notify the sender.  Thank you.
  
  
  
 

-
   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]
 
 
 
 
 
 
 __
 Do you Yahoo!?
 Check out the new Yahoo! Front Page.
 www.yahoo.com
 
 
 

-
 To unsubscribe, e-mail: [EMAIL PROTECTED]
 For additional commands, e-mail:
 [EMAIL PROTECTED]
 
 
 
 
 This e-mail, including any attachments, is a confidential business
 communication, and may contain information that is confidential,
 proprietary and/or privileged.  This e-mail is intended only

RE: sessionS info persistence when restart Tomcat

[Steve Kirk]

Following Yoav's earlier comments I've implemented a basic class
SessionLogger that implements HttpSessionListener,
HttpSessionActivationListener, HttpSessionAttributeListener,
ServletContextListener.  It just writes amessages to stdout using
System.out.println() to log when each event fires, including each of the
interface events plus instantiation and finalization of SessionLogger
itself.  I've configured it in web.xml:

listener
listener-classcore.servlet.SessionLogger/listener-class
/listener

SessionLogger logs its own presence OK when I instantiate it, and happily
logs events as expected on sessions, and session attributes.  It logs
context creation but not destruction.  Here's some sample catalina.log lines
for starting TC, logging in, logging out, logging in again:

2004-11-05 00:56:50 StandardContext[/ao]*** SERVLET CONTEXT: initialized
2004-11-05 00:58:08 StandardContext[/ao]*** SESSION EVENT: sessionCreated,
[EMAIL PROTECTED]
2004-11-05 00:58:23 StandardContext[/ao]*** SESSION ATTRIBUTE EVENT:
attributeAdded, LOGGED_IN_USER, [ID=1]
2004-11-05 00:58:30 StandardContext[/ao]*** SESSION ATTRIBUTE EVENT:
attributeRemoved, LOGGED_IN_USER, [ID=1]
2004-11-05 00:58:30 StandardContext[/ao]*** SESSION EVENT: sessionDestroyed,
[EMAIL PROTECTED]
2004-11-05 00:58:30 StandardContext[/ao]*** SESSION EVENT: sessionCreated,
[EMAIL PROTECTED]
2004-11-05 00:58:34 StandardContext[/ao]*** SESSION ATTRIBUTE EVENT:
attributeAdded, LOGGED_IN_USER, [ID=1]

However if I then stop TC, I get nothing logged at all after the
attributeAdded event.  The log just shows this as the last line:

05-Nov-2004 00:03:57 org.apache.coyote.http11.Http11Protocol pause INFO:
Pausing Coyote HTTP/1.1 on http-80

and there are no loglines to indicate that the
SessionLogger#sessionDestroyed, SessionLogger#contextDestroyed or
SessionLogger#finalize methods were called.

So it looks like sessions are working, but something is not working when TC
stops, and I suspect that this is why my sessions don't persist over
restarts.  I've read the docs and how-tos that I can find, plus googled
forum stuff on the web.  Does anyone have any insights please?

PS the above applies whether or not I explicitly add a Manager to my context
config.  Note that the standard config files for 5.0.28 do not explictly
include a Manager, but the docs say that A Manager element MAY be nested
inside a Context component. If it is not included, a default Manager
configuration will be created automatically.  I tried adding a Manager to
my context as follows just in case following Yoav's earlier comments: 
Manager className=org.apache.catalina.session.StandardManager
distributable=false debug=4 pathname=SESSIONS.ser / 
but this made no difference to the behaviour described above.

Another weird thing: if I trigger a webapp reload by rebuilding my warfile
while TC is running, TC complains about the absence of SESSIONS.ser - it
appears to be trying to persist sessions to the file - which it does not try
to do when I stop TC.  The log message is:

05-Nov-2004 00:23:26 org.apache.catalina.session.StandardManager doUnload
SEVERE: IOException while saving persisted sessions:
java.io.FileNotFoundException:
C:\jakarta-tomcat-5.0.28\work\Catalina\localhost\ao\SESSIONS.ser (The system
cannot find the path specified)

The file does not exist so the message sort of makes sense, except that this
does not happen if I stop and then start TC again - only if a reload is
triggered when I rebuild my warfile.

 -Original Message-
 From: Shapira, Yoav [mailto:[EMAIL PROTECTED] 
 Sent: Thursday 04 November 2004 16:09
 To: Tomcat Users List
 Subject: RE: sessionS info persistence when restart Tomcat
 
 
 
 Hi,
 
 I had always thought all sessions were lost when the server restarts.
 In
 fact I just tried it and confirmed that (5.0.28).  Are we 
 maybe talking
 about 2 different things?
 
 I think we're talking about the same thing.  Sessions are 
 supposed to be
 persisted by default.
 
 I have nonstandard config (a very sparse server.xml, no explicit
 Manager
 
 You need a Manager.  When I said by default I mean out of the box,
 i.e. with the default server.xml, which has such a Manager IIRC.
 
 Is this the manager config ref you were talking about?
 http://jakarta.apache.org/tomcat/tomcat-5.0-doc/config/manager.html
 
 Yeah.
 
 I just read through it.  If I've understood correctly, because my
 Manager
 is
 not explicitly configured, 
 
 There's a difference between not explicitly configured and 
 not declared
 at all.
 
 One way to test this is with an
 HttpSessionListener/HttpSessionActivationListener (one listener can
 implement both interfaces and thereby capture all four 
 relevant events).
 It's trivial to write one that just prints out information 
 when sessions
 are created, destroyed, passivated, and activated.
 
 Yoav
 
 
 
 This e-mail, including any attachments, is a confidential 
 business communication, and may contain information that is 
 confidential, proprietary

RE: sessionS info persistence when restart Tomcat

[Ben Souther]

SessionDestroyed shouldn't be called when tomcat shuts down. Otherwise,
the session wouldn't be valid when it starts up.  I just tested with a
clean install of 5.0.29 with a similar listener to the one you describe.
SessionDestroyed was not called when I stopped TC but the sessions were
still valid when I started it up.  I can give you the war file if you
like.

Do all of the attributes that you're adding to your session implement
Serializable?

 C:\jakarta-tomcat-5.0.28\work\Catalina\localhost\ao\SESSIONS.ser (The
system cannot find the path specified)
Does tomcat have sufficient permissions to write to the work directory?

How are you stopping Tomcat?



On Thu, 2004-11-04 at 20:15, Steve Kirk wrote:
 Following Yoav's earlier comments I've implemented a basic class
 SessionLogger that implements HttpSessionListener,
 HttpSessionActivationListener, HttpSessionAttributeListener,
 ServletContextListener.  It just writes amessages to stdout using
 System.out.println() to log when each event fires, including each of the
 interface events plus instantiation and finalization of SessionLogger
 itself.  I've configured it in web.xml:
 
 listener
   listener-classcore.servlet.SessionLogger/listener-class
 /listener
 
 SessionLogger logs its own presence OK when I instantiate it, and happily
 logs events as expected on sessions, and session attributes.  It logs
 context creation but not destruction.  Here's some sample catalina.log lines
 for starting TC, logging in, logging out, logging in again:
 
 2004-11-05 00:56:50 StandardContext[/ao]*** SERVLET CONTEXT: initialized
 2004-11-05 00:58:08 StandardContext[/ao]*** SESSION EVENT: sessionCreated,
 [EMAIL PROTECTED]
 2004-11-05 00:58:23 StandardContext[/ao]*** SESSION ATTRIBUTE EVENT:
 attributeAdded, LOGGED_IN_USER, [ID=1]
 2004-11-05 00:58:30 StandardContext[/ao]*** SESSION ATTRIBUTE EVENT:
 attributeRemoved, LOGGED_IN_USER, [ID=1]
 2004-11-05 00:58:30 StandardContext[/ao]*** SESSION EVENT: sessionDestroyed,
 [EMAIL PROTECTED]
 2004-11-05 00:58:30 StandardContext[/ao]*** SESSION EVENT: sessionCreated,
 [EMAIL PROTECTED]
 2004-11-05 00:58:34 StandardContext[/ao]*** SESSION ATTRIBUTE EVENT:
 attributeAdded, LOGGED_IN_USER, [ID=1]
 
 However if I then stop TC, I get nothing logged at all after the
 attributeAdded event.  The log just shows this as the last line:
 
 05-Nov-2004 00:03:57 org.apache.coyote.http11.Http11Protocol pause INFO:
 Pausing Coyote HTTP/1.1 on http-80
 
 and there are no loglines to indicate that the
 SessionLogger#sessionDestroyed, SessionLogger#contextDestroyed or
 SessionLogger#finalize methods were called.
 
 So it looks like sessions are working, but something is not working when TC
 stops, and I suspect that this is why my sessions don't persist over
 restarts.  I've read the docs and how-tos that I can find, plus googled
 forum stuff on the web.  Does anyone have any insights please?
 
 PS the above applies whether or not I explicitly add a Manager to my context
 config.  Note that the standard config files for 5.0.28 do not explictly
 include a Manager, but the docs say that A Manager element MAY be nested
 inside a Context component. If it is not included, a default Manager
 configuration will be created automatically.  I tried adding a Manager to
 my context as follows just in case following Yoav's earlier comments: 
 Manager className=org.apache.catalina.session.StandardManager
 distributable=false debug=4 pathname=SESSIONS.ser / 
 but this made no difference to the behaviour described above.
 
 Another weird thing: if I trigger a webapp reload by rebuilding my warfile
 while TC is running, TC complains about the absence of SESSIONS.ser - it
 appears to be trying to persist sessions to the file - which it does not try
 to do when I stop TC.  The log message is:
 
 05-Nov-2004 00:23:26 org.apache.catalina.session.StandardManager doUnload
 SEVERE: IOException while saving persisted sessions:
 java.io.FileNotFoundException:
 C:\jakarta-tomcat-5.0.28\work\Catalina\localhost\ao\SESSIONS.ser (The system
 cannot find the path specified)
 
 The file does not exist so the message sort of makes sense, except that this
 does not happen if I stop and then start TC again - only if a reload is
 triggered when I rebuild my warfile.
 
  -Original Message-
  From: Shapira, Yoav [mailto:[EMAIL PROTECTED] 
  Sent: Thursday 04 November 2004 16:09
  To: Tomcat Users List
  Subject: RE: sessionS info persistence when restart Tomcat
  
  
  
  Hi,
  
  I had always thought all sessions were lost when the server restarts.
  In
  fact I just tried it and confirmed that (5.0.28).  Are we 
  maybe talking
  about 2 different things?
  
  I think we're talking about the same thing.  Sessions are 
  supposed to be
  persisted by default.
  
  I have nonstandard config (a very sparse server.xml, no explicit
  Manager
  
  You need a Manager.  When I said by default I mean out of the box,
  i.e. with the default server.xml, which has such a Manager IIRC