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:
[EMAIL PROTECTED]
[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:
[EMAIL PROTECTED]
[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.
Login at the pluto debug output - ti seems as though Pluto somehow
*knows* that it is making a session for the first time... WHy not
have Pluto just wipe out anything that Tomcat happens to have laying
around in session related to this Portlet?
This is the version I am using
charles-severances-computer:~/dev/pluto-1.1/pluto-1.1 csev$ svn info
Path: .
URL: http://svn.apache.org/repos/asf/portals/pluto/trunk
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)
