You are viewing a plain text version of this content. The canonical link for it is here.
Posted to pluto-user@portals.apache.org by Nick Lothian <ni...@essential.com.au> on 2004/11/08 23:25:13 UTC

RE: How does a portlet know when to cleanup entity based resource s?

(Please don't CC multiple lists in your questions)

Answers inline

> -----Original Message-----
> From: ricky_frost@peoplesoft.com [mailto:ricky_frost@peoplesoft.com]
> Sent: Tuesday, 9 November 2004 5:09 AM
> To: general@portals.apache.org; pluto-user@portals.apache.org;
> pluto-dev@portals.apache.org; portlets@yahoogroups.com
> Cc: wsrp4j-user@ws.apache.org; wsrp4j-dev@ws.apache.org;
> wsrp@yahoogroups.com
> Subject: How does a portlet know when to cleanup entity based 
> resources?
> Importance: Low
> 
> 
> I've read the JSR-168 spec and I don't see a way of cleaning 
> up resources
> related to a user's use of a portlet (a single placement on a 
> page)... The
> only thing close which is talked about in the spec (PLT.5.2.5) is the
> portlet.destroy, which is not at all related to the portal 
> user doing a
> "logout" type of operation...
> 
> My assumptions are that the user can place a portlet on their 
> page at any
> time during their session in the portal and also remove it 
> from their page
> (without logging out of the portal). I'm assuming that if 
> they re-add my
> portlet during the same session I will pick up the state of 
> the prior use
> in the session (or not?). But what happens when they logout?
> 

The JSR-168 specification only specifies portlet behaviour, not portal
behavior. There is no requirement for portals to be consistent in their
behaviour when adding or removing portlets.


> The closest I can come to this functionality is to add a 
> session attribute
> that identifies the user-instance, then add a 
> HttpSessionBindingListener to
> that... and respond to the unbound event. Will this work for 
> all portals?
> 

Probably, but it isn't specified by JSR-168.

> p.s. This is of interest to me because of it's relation to the
> releaseSessions in WSRP... which could lead to D.O.S. 
> vulnerability if we
> just wait for the inactivity timeout.
> 
> Thanks for your time...
>