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!
\nI 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.
\n..\/work\/Catalina\/localhost\/sakai-portlets\/SESSIONS.ser
\nIf I am crazy – just tell me so.<\/p>\n
\nI have a portlet – with these lines at the beginning:
\npublic void doView(RenderRequest request, RenderResponse response)
\nthrows PortletException, IOException {
\nPortletSession pSession = request.getPortletSession(true);
\nString fred = (String) pSession.getAttribute(“fred”);
\nSystem.out.println(“Fred = “+fred);
\npSession.setAttribute(“fred”,”fred was here”);
\nThe “fred” attribute is used no where else in the portlet. Sometimes the portlet puts non-serializable stuff in session.
\n[DEBUG] PortletEntityImpl – Loading portlet definition for context: \/sakai-portlets[DEBUG] PortletEntityImpl – Retrieved cross context: org.apache.catalina.core.ApplicationContextFacade@5e2d6c
\n[DEBUG] PortletRequestImpl – Retreiving portlet session (create=true)[DEBUG] PortletRequestImpl – Creating new portlet session…
\nFred = null
\nRan the portlet in a way that puts a non-serializable thing in session.
\nShutdown Tomcat – got the following exception:
\nWARN: 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])
\njava.io.NotSerializableException: org.sakaiproject.portlets.SakaiLaunch$SakaiSite at java.io.ObjectOutputStream.writeObject0(ObjectOutputStream.java:1075)
\nat java.io.ObjectOutputStream.writeArray(ObjectOutputStream.java:1245) at java.io.ObjectOutputStream.writeObject0(ObjectOutputStream.java:1069)
\nat java.io.ObjectOutputStream.defaultWriteFields(ObjectOutputStream.java:1369) at java.io.ObjectOutputStream.defaultWriteObject(ObjectOutputStream.java:380)
\nat java.util.Vector.writeObject(Vector.java:1018)
\nI start Tomcat back up – the serialized file does not exist before I run my portlet:
\nls -l ..\/work\/Catalina\/localhost\/sakai-portlets\/SESSIONS.ser
\nls: ..\/work\/Catalina\/localhost\/sakai-portlets\/SESSIONS.ser: No such file or directory
\nWhen my portlet first runs, my session is clean:
\n[DEBUG] PortletRequestImpl – Retreiving portlet session (create=true)
\n[DEBUG] PortletRequestImpl – Creating new portlet session…
\nFred = null
\nThe serialization file does not exist.
\nls -l ..\/work\/Catalina\/localhost\/sakai-portlets\/SESSIONS.ser
\nls: ..\/work\/Catalina\/localhost\/sakai-portlets\/SESSIONS.ser: No such file or directory
\nRan ran portlet in such a way that the session data *was* all serializable.
\nShutdown Tomcat – no exceptions and SESSIONS.ser appears :(
\nls -l ..\/work\/Catalina\/localhost\/sakai-portlets\/SESSIONS.ser
\n-rw-r–r– 1 csev csev 2724 Aug 27 11:43 ..\/work\/Catalina\/localhost\/sakai-portlets\/SESSIONS.ser
\n*** Had the fred string in the file
\nStart Tomcat back up – no exceptions – everything is serializable – but the session stuff came back (i.e. the value for fred lasted across server reboots!)
\n[DEBUG] PortletEntityImpl – Loading portlet definition for context: \/sakai-portlets
\n[DEBUG] PortletEntityImpl – Retrieved cross context: org.apache.catalina.core.ApplicationContextFacade@d55e49
\n[DEBUG] PortletRequestImpl – Retreiving portlet session (create=true)
\n[DEBUG] PortletRequestImpl – Creating new portlet session…
\nFred = fred was here
\nThe workaround is to simply remove the ..\/work\/Catalina\/localhost\/sakai-portlets\/SESSIONS.ser each time it exists.
\nAnd even more clever workaround is to put something horrible and non-serializable in the session, each time.
\nThis 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.
\nIs 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.
\nThis is the version I am using
\ncharles-severances-computer:~\/dev\/pluto-1.1\/pluto-1.1 csev$ svn info
\nPath: .
\nRepository Root: http:\/\/svn.apache.org\/repos\/asf
\nRepository UUID: 13f79535-47bb-0310-9956-ffa450edef68
\nRevision: 434235
\nNode Kind: directory
\nSchedule: normal
\nLast Changed Author: cdoremus
\nLast Changed Rev: 434172
\nLast Changed Date: 2006-08-23 16:54:38 -0400 (Wed, 23 Aug 2006)
\nProperties Last Updated: 2006-05-11 09:16:39 -0400 (Thu, 11 May 2006)<\/p>\n","protected":false},"excerpt":{"rendered":"
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 […]<\/p>\n","protected":false},"author":2,"featured_media":0,"comment_status":"closed","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[1],"tags":[],"class_list":["post-192","post","type-post","status-publish","format-standard","hentry","category-uncategorized"],"_links":{"self":[{"href":"https:\/\/www.dr-chuck.com\/csev-blog\/wp-json\/wp\/v2\/posts\/192","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.dr-chuck.com\/csev-blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.dr-chuck.com\/csev-blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.dr-chuck.com\/csev-blog\/wp-json\/wp\/v2\/users\/2"}],"replies":[{"embeddable":true,"href":"https:\/\/www.dr-chuck.com\/csev-blog\/wp-json\/wp\/v2\/comments?post=192"}],"version-history":[{"count":1,"href":"https:\/\/www.dr-chuck.com\/csev-blog\/wp-json\/wp\/v2\/posts\/192\/revisions"}],"predecessor-version":[{"id":2293,"href":"https:\/\/www.dr-chuck.com\/csev-blog\/wp-json\/wp\/v2\/posts\/192\/revisions\/2293"}],"wp:attachment":[{"href":"https:\/\/www.dr-chuck.com\/csev-blog\/wp-json\/wp\/v2\/media?parent=192"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.dr-chuck.com\/csev-blog\/wp-json\/wp\/v2\/categories?post=192"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.dr-chuck.com\/csev-blog\/wp-json\/wp\/v2\/tags?post=192"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}