portals-jetspeed-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From raphael.l...@networks.groupvu.com
Subject Re: Portlet Caching problem
Date Tue, 02 Apr 2002 13:06:04 GMT
Santiago Gala wrote:
> raphael.luta@networks.groupvu.com wrote:
>> Caching:
>> --------
>> Caching is necessary for 2 reasons:
>> - avoid expensive convertion cycles from Entry -> PortletConfig
>>   (PortletFactoryService)
>>   This can simply be achieved by removing PortletConfig altogether and 
>> using
>>   directly an Entry associated to a Portlet.
> +1 We have suffered enough from PortletConfig already...
>> - prevent unnecessary instanciation of Portlet objects, this can be 
>> solved
>>   using a pool of objects that can be grabbed, associated to a state, 
>> executed
>>   & released (Turbine PoolService may be used for this purpose).
>> Now for this to be effective, it's critical that Portlet instances are 
>> not cached
>> within a user session else we can't release this object to the pool 
>> without making
>> the session incoherent.
>> Especially, use of PortletSet should be carefully monitored because 
>> this Portlet
>> instance stores a vector of Portlet objects...
>> (PortletSet is yet another evil interface created to circumvent a 
>> shortcoming
>>  of the initial interface, it should be deprecated and replaced by
>>  org.apache.jetspeed.om.profile.Portlets instances.)
>> In fact caching is going to keep being a huge mess unless there's a 
>> proper
>> separation of concerns between the "Portlet" API and the 
>> "PSML/Profile" API:
> If I follow correctly your ideas:
> - PSML/Profile API concern is layout of Portal pages, personalization, 
> customization
> - Portlet API concern is dealing with content to be rendered, void of 
> request/session and page/user context information. All request and 
> session state info should be dealt with using parameters in getContent() 
> (RunData for request info, Entry for page info)


> The current implementation has RunData as a repository for Request and 
> Session information, but we lack a similar abstraction for the 
> repository of Page/User information, short of data.getProfile()
>> If we can move all the data stateful information to the Profile API,
>> these objects can be properly cached in a user/shared/global data 
>> cache as
>> appropriate whereas the Portlet API can be moved to a pool-based caching
>> mechanism since these Portlet would only be executed and would not 
>> store any
>> user data.
>> At this stage, you only need to remove :
>> Portlet.getPortletConfig()
>> and add
>> Portlet.getContent(Rundata,Entry)
>> to have a servlet like Portlet object model and be very close to the 
>> new JSR API,
>> at least conceptually because they certainly aren't going to keep 
>> Rundata in the
>> top level Portlet API (yet another design issue with the current 
>> Jetspeed).
> Yes, but a Rundata is not that different from a cooked 
> ServletRequest/ServletResponse pair (or PortletRequest/PortletResponse), 
> so I see this one as a temporary problem, not as a conceptual one.

True, except that you actually have to cook the RunData object, you tie the
API to Turbine and you expose features you may not want to expose:
who *really* wants a Portlet to do a Turbine Rundata.setScreenTemplate() ? :P

> I have been thinking about the PortletWrapper wrapping the Entry 
> together with the Portlet, and this is definitely needed for the 
> PortletSetWrapper (as there is no direct access to the Entry from it).
> While my motivations were more aimed to avoid spoofing/security 
> problems, as the Entry stores the security constraints, it looked more 
> natural for a lot of other operations.
> So, at least for me, it makes a lot of sense.
> Note also that this proposal will still leave us with problems with the 
> RSSPortlet. The RSSPortlet is cached using Entry Parameters (items, 
> mediatype...), so when a RSSPortlet is called, it should be its 
> responsibility to check the parameters and return a "proper" content (as 
> it does now with media type).
> Possibly the best solution would be to give Portlets access to a generic 
> object caching API, and make caching of content a Portlet responsibility.

Actually they already have one, Turbine GlobalCache.
+1 for letting RSSPortlet handle its caching separately. Jetspeed has outgrown
simple RSS syndication and there should not be any architectural couplin anymore
between syndication and portal.

Raphael Luta - raphael.luta@networks.groupvu.com
Professional Services Manager
Vivendi Universal Networks - Paris

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