portals-jetspeed-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Glenn Golden <ggol...@umich.edu>
Subject RE: Portlet Caching problem
Date Tue, 02 Apr 2002 20:46:19 GMT
For RSS portlets, perhaps we can introduce a jetspeed RSS service.  This
would take care of fetching / caching the rss document, and perhaps provide
translation to html service (if this is startup intensize and would benefit
from some shared persistence).

The portlets would simply be an middle man, responsible for calling up the
appropriate service methods, based on the portlet instance configuration
(which url, other formatting parameters), whenever they had to provide
aggregation content.

This would be my approach to any "model" intensive portlet, anything making
heavy use of a database or business logic or external service.

I like to keep the portlet rather light weight, concerned with controller
and view aspects, user transaction state, and leave the heavy lifting to
services.

- Glenn

> -----Original Message-----
> From: Santiago Gala [mailto:sgala@hisitech.com] 
> Sent: Tuesday, April 02, 2002 6:22 AM
> To: Jetspeed Developers List
> Subject: Re: Portlet Caching problem
> 
> 
> 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>
> 

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