cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Carsten Ziegeler <>
Subject Re: ANN: [portal] New CachingPortletAdapter
Date Wed, 12 Jan 2005 12:01:43 GMT
DURDINA Michal wrote:
> 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.
Oh, that's bad and should imho be fixed.

> 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?
Do you mean that the CachingPortletAdapter then implements the caching 
of JSR-168 portlets as outlined in the spec? If so: +1
If not, we shouldn't imho invent our own caching mechanism that differs 
from the spec.


View raw message