Portlets are cached in the JetspeedPortletFactoryService. The handle is constructed by a static getHandle() method in the Portlet class (currently in AbstractPortlet) which is given only a PortletConfig. Since this is static, nothing about the Portlet except for the PortletConfig may be used to form the cache handle. The handle is formed from the URL, if this is set, and the init parameters. The factory service adds a hash of the class name to the handle.
Any portlet request checks what's in the cache, but only Portlets that implement the Cacheable interface are placed into the cache. Althought Cacheable has a setting to enable / disable caching, this is currently ignored by the Factory. Since most all Portlets extends AbstractPortlet, which is Cacheable, most all Portlets will be cached, like it or not. Based on a search of the code in CVS, only JspPortlet attempts in it's init() to turn off caching; my belief is that this is not being respected. This nixes any plans to extend AbstractPortlet to add a base Portlet class that will provide the ID as part of the handle. First, AbstractPortlet already defines the static getHandle() method, and second, the PortletConfig knows nothing about a portlet ID. Any Portlet code that needs to know its's own ID to properly getContent() that is cached and operating in an environment where there may be many placements of the Portlet on one or many Portal Pages, and there may be multiple concurrent requests for pages (such as from multiple users) WILL NOW FAIL. The one cached Portlet + PortletConfig will be retrieved for each request and MODIFIED to match the particular details of the request's portlet instance. Multiple threads will modify the same object and there's no guarantee that the modifications will be in place when they are needed. Another way to consider this is: If a Portlet's PortletConfig might be different in two different places, but the init parameters would be the same (and the url, if appropriate), then THIS WILL FAIL. To fully solve this, we can turn off caching completely (and see slower Jetspeed performance), turn it off for just those Portlets that need it off (but to do this we need to operate on the code, since caching is all or nothing currently), or include the Portlet's ID (and perhaps the portal page's profile id) in the cache (this will result in more copies of each portlet, but correct ones for those who care about instance. The RSS portlet is one that might not like this as it does much work in it's init and doesn't care much about portlet instance if the URLs match). I'm just looking for comments right now, while I ponder exactly what to do about caching. * * * Anybody want to vote to consider the caching broken right now because it ignores the Cachable isCacheable() setting? The JetspeedPortletFactoryService() could easily be "fixed" to check this before putting a Cacheable Portlet into the cache. I'll put my +1 on this. Anybody know of any objections to this? - Glenn --------------------------------------------------------------------- Glenn R. Golden Systems Research Programmer School of Information University of Michigan [EMAIL PROTECTED] 734-615-1419 --------------------------------------------------------------------- -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
