tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jacob Kjome <>
Subject RE: serialized objects invalidating session
Date Wed, 11 Aug 2004 04:37:56 GMT
Try using this session binding listener (see attached) with the following 
configuration in web.xml...


That should log any session activity as it happens.

BTW, you mentioned that you were implementing Serializable and then went on 
to say that you weren't doing anything with readObject() and writeObject() 
(which is perfectly fine), but never mentioned whether you had a member 
variable which wasn't, itself, Serializable.  This would cause your object 
to not be serializable.  Like I said before, try setting some strings to 
the session and see if they come back alright after restart.  You might 
also want to delete the "work" directory and start fresh.  Have you done 
anything with Tomcat's configuration?  If so, try blowing away Tomcat and 
starting fresh.  Tomcat persists sessions just fine.  Take Yoav's advice 
and do a serialization test outside the container using 
ObjectOutputStream.  For instance...

String hello = "hello world";
ByteArrayOutputStream byteOut = new ByteArrayOutputStream();
ObjectOutputStream objectOut = new ObjectOutputStream(byteOut);
ByteArrayInputStream byteIn = new ByteArrayInputStream(byteOut.toByteArray());
ObjectInputStream objectIn = new ObjectInputStream(byteIn);
String helloDeserialized = (String) objectIn.readObject();

Just replace the "hello" string with your own object and see what happens.

BTW, the stdOut.log file getting cleared upon restart is expected behavior.


At 08:41 PM 8/10/2004 -0500, you wrote:
>Hi Yoav,
>Thanks for your help, but I give up. I can't persist a session anymore
>if my life depended on it :-) I tried putting the distributable element
>in my application web.xml, in my context xml file in Tomcat (in the
>conf/Catalina/localhost/appname.xml file, and in the server.xml file,
>but to no avail. I set it to true, to false, and no matter what I could
>not create a SESSION.SER file anywhere. I monitored the sessions through
>the Management console, and it always went back to 0 after a Tomcat
>start and stop. At least with 5.0.19 I could get my sessions to persist
>if I didn't serialize any of the objects in the sessions. One other
>thing I noticed with 5.0.27 is that when you stop and start, the stdXXX
>log files get deleted automatically, which I guess is a good thing/bad
>thing depending on your need to see what has transpired over a period of
>Thanks again for your help!
>-----Original Message-----
>From: Shapira, Yoav []
>Sent: Tuesday, August 10, 2004 12:17 PM
>To: Tomcat Users List
>Subject: RE: serialized objects invalidating session
> >My first question
> >is is there a configuration parameter I need to set to allow Tomcat to
> >serialize the sessions in 5.0.27?
>Tomcat serializes sessions by default, as required by the Servlet
>Specification.  This specific behavior is controlled by the Manager
>element in your server.xml (this is not the same as the Manager webapp),
>whose docs are at
> >... or what may be happening is that
> >per Jacob's response, there is some other object in the session that
> >does not implement the Serializable interface, so therefore, the whole
> >thing is trashed. FYI, my object is simply implementing the
> >interface. I am doing nothing else like implementing readObject,
> >writeObject, etc..
>You don't need to implement the custom serialization methods: declaring
>that you implement Serializable is sufficient.  You can test to see if
>your class is serializable by trying to serialize it outside of Tomcat,
>it's pretty trivial to do with a ByteArrayOutputStream.  Or
>commons-lang's SerializationUtils.
>Try setting the distributable flag of your Context to true.  Let us know
>if the behavior changes then.
>The relevant code is at
>specifically the writeObject method.  Non-Serializable attributes are
>Yoav Shapira
>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:
>For additional commands, e-mail:
>To unsubscribe, e-mail:
>For additional commands, e-mail:

View raw message