cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "DURDINA Michal" <>
Subject RE: ANN: [portal] New CachingPortletAdapter
Date Mon, 10 Jan 2005 12:22:38 GMT
> -----Original Message-----
> From: Carsten Ziegeler []
> Sent: Friday, January 07, 2005 5:46 PM
> To:
> Subject: Re: ANN: [portal] New CachingPortletAdapter
> DURDINA Michal wrote:
> > Sorry for just a quick response.
> > 
> > JSR168 - portlet specification really defines something 
> like "expiration cache", which when set to -1 should provide 
> caching of portlet content. 
> > 
> > But as I see it:
> >  * according to spec, implementation of caching is optional 
> for portlet container
> >  * content would be cached also with translated links 
> (conflict with DefaultEventConverter - that generates links 
> only with one request validity)
> >  * portal samples already contains 
> <expiration-cache>-1</expiration-cache> but caching is not 
> working (try to output current time in TestPortlet - it will 
> always refresh)
> >  * yet must investigate pluto distribution wheter caching 
> is supported by pluto container at all
> > 
> If the caching as outlined in the spec is not working in 
> Cocoon, we have 
> to first fix this to be jsr 168 compliant. So, let's wait for 
> the results.
> Carsten

I checked Pluto 1.0.1-rc1 (and also trunk) and the result is: pluto portal (/portal) does
not implement caching yet. The portlet.xml expiration-cache element is parsed in PortletDefinitionImpl
but never read (checked with Eclipse -> References). The same is valid for cocoon.

IMHO it is the responsibility of the portal to implement caching not of portlet container.
I think there is nothing to fix in cocoon to enable caching. We have to implement caching
in cocoon and pluto portal (/portal subproject) should implement caching its own way. Caching
implementation involves no changes in pluto container (/container subproject) that the cocoon
is dependent on.

I suggest I can slightly modify the CachingPortletAdapter to adapt for PortletDefinitionImpl.getExpirationCache()
value. Original PortletAdapter can stay untouched and users would have to use new CachingPortletAdapter
to enable caching in their portals. I think it is better to provide caching in the new adapter,
because users that already used PortletAdapter depend on non-caching behaviour (regardless
of <expiration-cache> value in their portlet.xml). WDYT?

I can provide a new patch to bugzilla or only difference to my current patch and I would be
happy if somebody could take a look at it afterwards.

Thank you,

View raw message