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 05:43:37 GMT


> -----Original Message-----
> From: Glenn Golden [mailto:ggolden@umich.edu] 
> Sent: Monday, April 01, 2002 9:09 PM
> To: 'Jetspeed Developers List'
> Subject: RE: Portlet Caching problem
> 
> 
> 
> > -----Original Message-----
> > From: David Sean Taylor [mailto:david@bluesunrise.com]
> > Sent: Monday, April 01, 2002 11:34 PM
> > To: 'Jetspeed Developers List'
> > Subject: RE: Portlet Caching problem
> 
> > Portlet.getID() should always delegate to its portlet instance. 
> > Perhaps it should be Portlet.getInstance().getId() and deprecate
> > Portlet.getID()
> > Same goes for title and description.
> > Although the title and description should be able to fallback to the
> > Configuration meta info.
> > I believe that is what is attempted via PortletConfig.
> 
> What do you mean by getInstance() here? I don't see it in 
> org.apache.jetspeed.portal.Portlet now...

It was just an idea. 

> 
> I've been thinking about the relationship between the Entry 
> (from the psml file, an om? Peer? Class) and Portlet... If 
> the Profiler loaded docs in such as way as to make the Entrys 
> available, then instead of copying the Entry info into the 
> Portlet, we could so some pointing...

The entries are available. Everything is navigatable from the root
Portlets object on down.
I also have on my todo list to make a hashtable in the psml doc into
every entry by id

> 
> I think we need to carefully look at / rethink the three 
> services: Profiles, JetspeedPortletFactoryService, and 
> JetspeedPortalToolkitService.  Profiler provides the psml 
> doc, tooklit service creates a portlet set, and uses the 
> factory and its caching to get Portlet objects.
> 
> * * *
> 
> My tests tonight confirm that the caching is improperly (as 
> far as peid and meta is concerned) reusing Portlet objects, 
> and that if the portal page + peid is made part of the cache 
> handle, this reuse stops.  This may be more severe than we 
> want, and a re-org of the three services involved may produce 
> a much more efficient and correct situation.
> 

What about adding AbstractIdentityPortlet that uses the psml-id + peid
for its cache handle.

	AbstractPortlet
	    |
	AbstractIdentityPortlet
	    |
       VelocityPortlet
	    ....

As for RSS portlets or other shared portlets, getting the id is still
problematic.
I'd like to work out how we get the instance Id on a portlet.
To the portlet, the instance is transient state per request.
As we are aggregating, we need to find out the portlet id from the PSML
document.
As far as the portlet is concerned, it changes per request.



> Also noticed that the PortletWrapper objects are not cached, 
> and are being created and used once and thrown away for each 
> wrapped portlet.  Messy.
> 
> - Glenn 
>  
> --------------------------------------------
> Glenn R. Golden, Systems Research Programmer
> University of Michigan School of Information
> ggolden@umich.edu               734-615-1419
> http://www-personal.si.umich.edu/~ggolden/
> --------------------------------------------
> 
>  
> 
> --
> To unsubscribe, e-mail:   
> <mailto:jetspeed-dev-> unsubscribe@jakarta.apache.org>
> For 
> additional commands, 
> e-mail: <mailto:jetspeed-dev-help@jakarta.apache.org>
> 
> 



--
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