Pluto 1.1 Bug Session’s living across server restart

There is a bug (I think) in session handling in Pluto 1.1. Why would Pluto 1.1 keep a session across a Tomcat restart!
I think that this has to do with Tomcat’s session serialization across startups and Pluto’s blind dependence on Tomcat session for storing the Pluto session.
../work/Catalina/localhost/sakai-portlets/SESSIONS.ser
If I am crazy – just tell me so.


I have a portlet – with these lines at the beginning:
public void doView(RenderRequest request, RenderResponse response)
throws PortletException, IOException {
PortletSession pSession = request.getPortletSession(true);
String fred = (String) pSession.getAttribute(“fred”);
System.out.println(“Fred = “+fred);
pSession.setAttribute(“fred”,”fred was here”);
The “fred” attribute is used no where else in the portlet. Sometimes the portlet puts non-serializable stuff in session.
[DEBUG] PortletEntityImpl – Loading portlet definition for context: /sakai-portlets[DEBUG] PortletEntityImpl – Retrieved cross context: org.apache.catalina.core.ApplicationContextFacade@5e2d6c
[DEBUG] PortletRequestImpl – Retreiving portlet session (create=true)[DEBUG] PortletRequestImpl – Creating new portlet session…
Fred = null
Ran the portlet in a way that puts a non-serializable thing in session.
Shutdown Tomcat – got the following exception:
WARN: Cannot serialize session attribute javax.portlet.p./sakai-portlets.SakaiLaunch?site.list for session 77C3CD8BE5687531A4BA57BC87AFCB5C (2006-08-27 11:53:07,973 main_org.apache.catalina.core.ContainerBase.[Catalina].[localhost].[/sakai-portlets])
java.io.NotSerializableException: org.sakaiproject.portlets.SakaiLaunch$SakaiSite at java.io.ObjectOutputStream.writeObject0(ObjectOutputStream.java:1075)
at java.io.ObjectOutputStream.writeArray(ObjectOutputStream.java:1245) at java.io.ObjectOutputStream.writeObject0(ObjectOutputStream.java:1069)
at java.io.ObjectOutputStream.defaultWriteFields(ObjectOutputStream.java:1369) at java.io.ObjectOutputStream.defaultWriteObject(ObjectOutputStream.java:380)
at java.util.Vector.writeObject(Vector.java:1018)
I start Tomcat back up – the serialized file does not exist before I run my portlet:
ls -l ../work/Catalina/localhost/sakai-portlets/SESSIONS.ser
ls: ../work/Catalina/localhost/sakai-portlets/SESSIONS.ser: No such file or directory
When my portlet first runs, my session is clean:
[DEBUG] PortletRequestImpl – Retreiving portlet session (create=true)
[DEBUG] PortletRequestImpl – Creating new portlet session…
Fred = null
The serialization file does not exist.
ls -l ../work/Catalina/localhost/sakai-portlets/SESSIONS.ser
ls: ../work/Catalina/localhost/sakai-portlets/SESSIONS.ser: No such file or directory
Ran ran portlet in such a way that the session data *was* all serializable.
Shutdown Tomcat – no exceptions and SESSIONS.ser appears :(
ls -l ../work/Catalina/localhost/sakai-portlets/SESSIONS.ser
-rw-r–r– 1 csev csev 2724 Aug 27 11:43 ../work/Catalina/localhost/sakai-portlets/SESSIONS.ser
*** Had the fred string in the file
Start Tomcat back up – no exceptions – everything is serializable – but the session stuff came back (i.e. the value for fred lasted across server reboots!)
[DEBUG] PortletEntityImpl – Loading portlet definition for context: /sakai-portlets
[DEBUG] PortletEntityImpl – Retrieved cross context: org.apache.catalina.core.ApplicationContextFacade@d55e49
[DEBUG] PortletRequestImpl – Retreiving portlet session (create=true)
[DEBUG] PortletRequestImpl – Creating new portlet session…
Fred = fred was here
The workaround is to simply remove the ../work/Catalina/localhost/sakai-portlets/SESSIONS.ser each time it exists.
And even more clever workaround is to put something horrible and non-serializable in the session, each time.
This seems like a very bad policy – that portlet session data lives beyond server restart. This looks like it is Tomcat doing the session management and Pluto 1.1 is just using the Tomcat Session to store the data – but we do need inside portlets to know when we are being run for the first time for a new user to do things like log in and retrieve web services.
Is there something in my portlet.xml to say “I would like (DUH) a fresh session when the server restarts” – or is this unspecified behavior – i it is unspecified – the Pluto 1.1 behavior is wrong.
This is the version I am using
charles-severances-computer:~/dev/pluto-1.1/pluto-1.1 csev$ svn info
Path: .
Repository Root: http://svn.apache.org/repos/asf
Repository UUID: 13f79535-47bb-0310-9956-ffa450edef68
Revision: 434235
Node Kind: directory
Schedule: normal
Last Changed Author: cdoremus
Last Changed Rev: 434172
Last Changed Date: 2006-08-23 16:54:38 -0400 (Wed, 23 Aug 2006)
Properties Last Updated: 2006-05-11 09:16:39 -0400 (Thu, 11 May 2006)