portals-jetspeed-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "David Sean Taylor" <da...@bluesunrise.com>
Subject RE: Portlet Caching problem
Date Tue, 02 Apr 2002 02:57:48 GMT

Please consider that RSS portlets do want to be shared across multiple
users and instances.
With anytype of content feed in general or shared resource, we don't
want content per instance.
Thus, the default mode of portlet caching *must* work exactly as it
works now for backward compatibility.
Not to mention having multitudes of un-necessary RSS feeds in memory.

I've added several parameters recently to the registry to aid in


By default they are all set to true - so that we don't screw up shared
resources (RSS).

isCachedOnURL() is the only functional parameter right now. The other
two will require refactoring of PortletConfig which looks a bit messy.

If you want your portlet to be cached based on the psml-id + id, simply
override the getHandle() in your portlet class or some base class. But
please do not change AbstractPortlet's default behavior.

> When any of this information changes, due to a re-load of the 
> registry, or a customization of the portlet on the page, we 
> must invalidate this object from the cache!

Yes, when you reload a portlet from the registry, I would hope that it
gets expired.
Are you saying that it doesn't?

> Two of the same portlets on the same page need to have 
> different Portal objects (these have different peids, at 
> least, and maybe different psml parameters).
> Two of the same portlets on different portal pages need to 
> have different Portal objects as well, for the same reason.
> A cached Portlet object could be reused for subsequent page 
> requests, and for page requests from other users viewing the 
> same page.  And only this - any other use of the portlet 
> would be a different portlet instance and need a different 
> Portlet object.
> So, a good handle for caching of one of these Portlet objects 
> would be the portlet's PEID, plus the portal page's unique 
> id.  The parameters don't matter, nor does the ancestry or 
> meta information, nor does the portlet class.
> I'll start making this change, if I hear a positive sanity 
> check from the developers.

Please don't change AbstractPortlet.
Why not change getHandle in VelocityPortlet or come up with a new class

SharedPortlet          InstancePortlet

> Do we have anything from a portal page (or from the root 
> portlet set element in a page) that can be used for a unique 
> portal page id?  I need it for this (and other purposes!).  
> The file name is ok, but probably won't work for database 

Don't use the filename, it doesn't work with the DB version and is not
The profiler, given a profile, can easily generate a standard, unique
string identifying the page in a format such as:

   /group/<group_name>   - no default group_name
   /role/<role_name>     - no default role_name
   /user/<user_name>     - defaults to the current user

   /page/<page_name>     - defaults to /page/default (or what ever is
                           configured in JR.p
   /js_pane/<peid>       - Can not be used with /js_pane
                           Defaults to the root element (pane or
   /js_peid/<peid>       - Can not be used with /js_peid
                           Defaults to the root element (pane or
   /action/<action_name> - no default action_name

I believ Paul was working on this for the JetspeedTemplateLink. 

> versions... Do we need to add a new PEID for this at the portal level?

Org.apache.jetspeed.om.profile.psml.PsmlPortlets is an IdentityElement,
i.e. it has an ID.

To unsubscribe, e-mail:   <mailto:jetspeed-dev-unsubscribe@jakarta.apache.org>
For additional commands, e-mail: <mailto:jetspeed-dev-help@jakarta.apache.org>

View raw message