One other thing I forgot to mention, and I don't know if this means anything, but one thing I noticed when stopping Tomcat5.0.19, it sent to stdout some detailed output about serializing objects and persisting my session. But with Tomcat5.0.27, the only thing that appeared in stdout was the following;
INFO: Pausing Coyote HTTP/1.1 on http-8080 Regards, Carey -----Original Message----- From: Carey Boldenow [mailto:[EMAIL PROTECTED] Sent: Wednesday, August 11, 2004 9:35 AM To: 'Tomcat Users List' Subject: RE: serialized objects invalidating session First off. Thanks Jacob for that listener class, it really provided me a great help. I meticulously went through all my code and did in fact find some member objects that also needed to implement the Serializable interface. I refactored those and reinstalled 5.0.27 to get a fresh implementation. However, when I exercised my code, once again there was no sign of my session and therefore my other serialized objects after stopping/restarting tomcat. I searched for any SESSION.SER file and was unable to find anything. I then reinstalled 5.0.19 and again exercised my code and wholla, SUCCESS! The session and all my objects were reserialized correctly after stopping/starting Tomcat. I certainly am not saying there is something wrong with the 5.0.27 release, it may be that my code simply does not strictly abide by the servlet spec and 5.0.19 is more forgiving with regards to that. Regards, Carey -----Original Message----- From: Jacob Kjome [mailto:[EMAIL PROTECTED] Sent: Tuesday, August 10, 2004 10:38 PM To: Tomcat Users List Subject: RE: serialized objects invalidating session Try using this session binding listener (see attached) with the following configuration in web.xml... <listener> <listener-class>org.mypackage.servlet.MySessionBindingListener</listener -class> </listener> 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); objectOut.writeObject(hello); objectOut.close(); 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. Jake 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 >time. > >Thanks again for your help! >Carey > >-----Original Message----- >From: Shapira, Yoav [mailto:[EMAIL PROTECTED] >Sent: Tuesday, August 10, 2004 12:17 PM >To: Tomcat Users List >Subject: RE: serialized objects invalidating session > > >Hi, > > >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 >http://jakarta.apache.org/tomcat/tomcat-5.0-doc/config/manager.html. > > > >... 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 >Serializable > >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 >http://cvs.apache.org/viewcvs.cgi/jakarta-tomcat-catalina/catalina/src/ s >hare/org/apache/catalina/session/StandardSession.java?view=markup, >specifically the writeObject method. Non-Serializable attributes are >unbound. > >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: [EMAIL PROTECTED] >For additional commands, e-mail: [EMAIL PROTECTED] > > >--------------------------------------------------------------------- >To unsubscribe, e-mail: [EMAIL PROTECTED] >For additional commands, e-mail: [EMAIL PROTECTED] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
