Charles Severance wrote:
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!
Chuck,
Have you tried putting a <Manager pathname=""/> element in your
context.xml? The context.xml should be in
conf/Catalina/localhost/sakai-portlets.xml. That should disable session
persistence across restarts for that context.
See also:
http://tomcat.apache.org/tomcat-5.5-doc/config/manager.html#Standard%20Implementation,
scroll down to the "pathname" attribute and also
http://tomcat.apache.org/tomcat-5.5-doc/config/manager.html#Restart%20Persistence
HTH,
Elliot
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)
