> -----Original Message----- > From: Carsten Ziegeler [mailto:[EMAIL PROTECTED] > Sent: Friday, January 07, 2005 5:46 PM > To: dev@cocoon.apache.org > 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, Michal
