portals-jetspeed-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Santiago Gala <sg...@hisitech.com>
Subject Re: Portlet Caching problem
Date Tue, 02 Apr 2002 10:59:06 GMT
Glenn Golden wrote:

(...snip...) See comments by Raphael below

>
>Also noticed that the PortletWrapper objects are not cached, and are being
>created and used once and thrown away for each wrapped portlet.  Messy.
>
The PortletWrappers are quite lightweight objects, which do not need a 
costly initialization.

I agree that they could/should be pooled, but not cached as such. When 
we do have a facade for Portlets/PortletSet, we can use this facade to 
recycle PortletWrappers pointed by it (a PortletSetWrapper is a 
container-private object that could know that PortletWrappers exist). 
Don't forget that PortletWrappers are facades which must *not* be made 
visible to non-core code at all. They are there to ensure that the 
Portlets are protected from casts and do not expose any non intended 
public methods.

I introduced them in a way that required very little changes in the 
current code (just instantiation in the factory).

On the other side, the issues with caching are not so much related with 
memory management (which we are solving with pooling mostly) but with 
costly initialization. To show an example, each RSSPortlet needs to 
fetch a URL, generate a XSLT stylesheet and apply a transformation to 
get the content, which are very costly operations.

The current handle uses (should use) the config parameters because they 
are used in the transformation (items, showtitle,...)

One thing I never really liked is that AbstractPortlet is not an 
abstract class, but it imposes very concrete assumptions on the life 
cycle and behaviour of a portlet.

Maybe the time is coming when AbstractPortlet is substituted by a set of 
classes for different life cycle modes, along the lines that David 
suggested.

But let us discuss thoroughly the issues so that we can have it nailed 
reasonably this time. :)


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


Mime
View raw message