Yes Ate is correct, and also here's a couple of likely links to Jetspeed and Liferay issue trackers where I believe they have dealt with the same requirement you are trying to deal with:
http://issues.apache.org/jira/browse/JS2-582 http://issues.liferay.com/browse/LEP-1466 I've not reviewed those issues, but I can image that the Portal context needs to propagate the session invalidation to the Portlet context. Brett On Wed, Nov 18, 2009 at 8:26 PM, Ate Douma <[email protected]> wrote: > Portlet 2.0 spec PLT.18.4 (and for that matter the whole of the Portlet > spec) *only* talks about the *Portlet* application, not the *Portal* > application. > This means, the portlet *container* is required to invalidate the servlet > (application) session when the portlet session is invalidated, and this is > properly implemented in the Pluto container. > You should not confuse this with the (limited) behavior of the Pluto > *Portal* Driver, which primarily purpose is only to serve as testbed for the > Pluto container, not a full blown, production ready, portal. > Handling logout *across* portlet applications hosted by the Pluto Portal > Driver simply isn't implemented as it not needed for *testing* the Pluto > Container itself. > > The Pluto Portal Driver, while actually used by some for production > purposes, really is not targeted nor maintained for such usages. > > If you need such functionality (and/or similar production quality features > like persistence, better (session) navigation state/url handling, etc., > etc.) you either have to add this yourself or probably better switch using a > full blown portal like Apache Jetspeed-2 or others which does provide all > such features. > > HTH, > > Ate > > > hub wrote: > >> Brett, >> After logout / login I see the same session attributes as I set before in >> the portlet session. >> I noticed that my, "valueUnbound()" method for attributes in the portlet >> session is not called for the cleanup I need to do on logout / "portal >> session invalidation". I then set portlet session expiration time to a >> short >> period to check, if valueUnbound() is called at all, ... it is, also on >> application shutdown. >> The session.invalidate() on logout is run in a jsp in "portal context". >> After login with different username I have a different principal in the >> portlet session, but same session attributes as set before. >> >> >> javabrett wrote: >> >>> If the HttpSession object is invalidated, the PortletSession object must >>> also be invalidated by the portlet container. >>> >>> >> I read the same here for JSR 168: >> >> http://opensource.atlassian.com/confluence/spring/pages/viewpage.action?pageId=3131 >> >> I have set emptySessionPath="true" in server.xml. >> running on JBoss GA 4.2.2, Tomcat version is 6.0.20 >> >> >> Thank you >> hub >> >> >> javabrett wrote: >> >>> According to Portlet 2.0 spec PLT.18.4: >>> >>> If the HttpSession object is invalidated, the PortletSession object >>> must >>> also be invalidated by the portlet container. >>> >>> How do you detect that your portlet sessions are not being invalidated? >>> >>> Brett >>> >>> On Tue, Nov 17, 2009 at 10:09 PM, hub <[email protected]> wrote: >>> >>> Hello, >>>> How do I invalidate all portlet sessions on logout? >>>> >>>> in my logout.jsp in the portal I do the following >>>> <% >>>> session.invalidate(); >>>> %> >>>> >>>> This invalidates the "portal" session but my portlet sessions are not >>>> invalidated. >>>> >>>> >> >
