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 11:22:24 GMT
raphael.luta@networks.groupvu.com wrote:

> [warning, ramblings ahead...]
>
> First, Glenn you're completely right the Portlet caching as currently
> implemented in Jetspeed is screwed up.
> Second, there is an incoherence between Portlet/PortletConfig and PSML 
> that
> is mainly legacy based :
> when Kevin started Jetspeed there was no PSML and the the 
> PortletConfig was how
> Jetspeed stored its portlet parameters and caching was applied on Portlet
> + PortletConfig; when I added PSML support I could not remove the 
> PortletConfig at
> the time so we end up creating objects like this:
>
> PSML file ---> PSML Entry objects --------------> Portlet + PortletConfig
>                                        ^
>                             PortletSetFactory
>
> which neither very clean design, nor very efficient.
>
> In fact now that David has completed the move of the PSML 
> implementation to an
> interface based API, PortletConfig is truly completely redundant and 
> *should*
> be replaced directly by a org.apache.jetspeed.om.profile.Entry 
> implementation.
>
> 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.

>
> I hope this made sense at least in some parts. ;)


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.



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