RE: sessionS info persistence when restart Tomcat

2004-12-10 Thread 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?
>> >>
>> >>
>> 

RE: sessionS info persistence when restart Tomcat

2004-12-10 Thread 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

2004-12-10 Thread 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

2004-12-10 Thread 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

2004-12-10 Thread 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

2004-12-10 Thread 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

2004-12-10 Thread 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

2004-12-10 Thread 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
> &g

AW: sessionS info persistence when restart Tomcat

2004-12-10 Thread Michael Sudkamp
Hi Steve,

I am jumping into this discussion rather late and I am probably not going to
answer any of your questions. I just would like to add that I examined the
session persistence and listeners topic also very deep some weeks ago. After
all I found it not really practical because the servlet 2.3/2.4 spec is not
clear enough about how the sequence the variuos listeners should be called
by the container. In my case it was vital that the contextInitialized()
method must be called before sessionActivated(). This because in
sessionActivated we restore our transient members and for this WE need a
fully initialized ServletContext (and preferably also the init() methods of
preloaded servlets have been called).

Yoav confirmed me that it is a spec problem and encouraged me to contact the
spec group, what I did. They told me that  they will address the problem in
a next spec.

Michael


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


RE: sessionS info persistence when restart Tomcat

2004-12-10 Thread 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.
> > > 
> > > Yo

RE: sessionS info persistence when restart Tomcat

2004-12-09 Thread 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, HttpSessionAttributeListene

RE: sessionS info persistence when restart Tomcat

2004-11-05 Thread 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

2004-11-05 Thread 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

2004-11-05 Thread 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

2004-11-05 Thread 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:












> 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

RE: sessionS info persistence when restart Tomcat

2004-11-05 Thread 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 h

RE: sessionS info persistence when restart Tomcat

2004-11-05 Thread 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

2004-11-05 Thread 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

2004-11-05 Thread 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:
> > >>
> > >> 
> > >>  core.servlet.SessionLogger
> > >> 
> > >>
> > >> 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
> > &

RE: sessionS info persistence when restart Tomcat

2004-11-05 Thread 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:
> >>
> >> 
> >>core.servlet.SessionLogger
> >> 
> >>
> >> 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 , 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:
> >

RE: sessionS info persistence when restart Tomcat

2004-11-05 Thread Steve Kirk
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: 
> >  > 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.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

2004-11-05 Thread 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:
>>
>> 
>>  core.servlet.SessionLogger
>> 
>>
>> 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 , 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:
>> > 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.FileNotFoundExce

RE: sessionS info persistence when restart Tomcat

2004-11-04 Thread 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:
> 
> 
>   core.servlet.SessionLogger
> 
> 
> 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 , 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: 
>  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 ju

RE: sessionS info persistence when restart Tomcat

2004-11-04 Thread 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:


core.servlet.SessionLogger


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 , 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: 
 
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 activa

RE: sessionS info persistence when restart Tomcat

2004-11-04 Thread 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.
> &g

RE: sessionS info persistence when restart Tomcat

2004-11-04 Thread 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 use

RE: sessionS info persistence when restart Tomcat

2004-11-04 Thread 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

2004-11-04 Thread 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

2004-11-04 Thread 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

2004-11-04 Thread 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]



sessionS info persistence when restart Tomcat

2004-11-04 Thread Mark
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]