The caching features in jsr 286 portlets.

The JSR 286 specification added the following two new caching features:
1. Public cache scope: the cache entries are shared across users
2. Validation based caching: expired cache entries can be validated using ETag
But there in JSR 168, only "Expiration" cache was supported. And also the cache is per user client and not shared across users.
Public Cache Scope You can tell the Portlet Container that the cache entry can be shared across users. This can be done by setting the value of element to public.The default value is "private" which behaves like the JSR 168 caching where the cache is per user. The cache scope can also be changed programmatically using a response property(i.e MimeResponse.PUBLIC_SCOPE, MimeResponse.PRIVATE_SCOPE) or the new CacheControl interface(i.e response.getCacheControl().setPublicScope(true).)



Validation based Caching Validation" caching is supported along with "Expiration" caching. After the cache has expired the portlet has the option to check if the cache is still valid and indicate that the cache can be reused. To enable this, ETag has been introduced, which is similar to how the browsers, which conform to HTTP 1.1, perform caching. Once the cache has expired the Portlet Container calls the render/serveResource method with the ETag set in the RenderRequest/ResourceRequest, which the portlet can access and check if the cache is still valid. If the cache is still valid, then the portlet can set CacheControl.setUseCachedContent(true) in the response, and the new expiration time.

protected void doView (RenderRequest request, RenderResponse response)    throws PortletException, IOException {
   …
   if ( request.getETag() != null ) { // validation request
      if ( markupIsStillValid(request.getETag()) ) {
          // markup is still valid
          response.getCacheControl().setExpirationTime(30);
          response.getCacheControl().setUseCachedContent(true);
         return;
       }
   }
   // create new content with new validation tag
   response.getCacheControl().setETag(someID);
   response.getCacheControl().setExpirationTime(60);
   PortletRequestDispatcher rd = getPortletContext().getPortletRequestDispatcher(“view.jsp”);      rd.include(request, response);
}

The introduction of ETag ensures that the browser can be leveraged to cache resources and markup. With the new features of public sharing of caches, resource caching, validation caching and leveraging browser caching, the performance of aggregation of portlets by a portal can be seen to increase significantly.

How to write the portlet filter ?

You can write a portlet filter in geven two steps:

Step 1 - Write a filter class: A filter class should implement one or more of the above mentioned four interfaces and should provide a no argument public constructor. The filter class should also override the init() and destroy() methods of the javax.portlet.filter.PortletFilter interface.



Step 2 - Filter and filter mapping: Define the filter and filter mapping in the portlet.xml . This is done using the element, where you also need to specify the lifecycle call to which the filter should be applied. In the element you describe to which portlets the filter should be applied. If you want the filter to be applied to all portlets in the application, you need to used an asterisk as a wildcard.

What are the Portlet Filters ?

A portlet filter is same as a servlet filter. The only difference is that a servlet has only one request handling method, service() and therefore there is only one type of the servlet filter. A portlet on the other hand has four types of request handling methods and therefore there are four different types of portlet filters.

The portlet API defines the following interfaces for creating portlet filters:
javax.portlet.filter.ActionFilter - For processAction method
javax.portlet.filter.EventFilter - For processEvent method
javax.portlet.filter.RenderFilter - For render method
javax.portlet.filter.ResourceFilter - For serveResource method

Each of the above filter interface contains a single doFilter(Request, Response, FilterChain chain) method which differs in the type of request and response object. For example, the doFilter() method of ActionFilter takes instances of ActionRequest and ActionResponse objects while the doFilter() method of RenderFilter takes instances of the RenderRequest and RenderResponse.

Each filter interface extends a common base interface called javax.portlet.filter.PortletFilter. This common base interface contains two methods:
init(javax.portlet.filter.FilterConfig filterConfig) and destroy(). The init() method makes sure that every filter has access to a FilterConfig object from which it can obtain its initialization parameters, a reference to the PortletContext which it can use, for example, to load resources needed for filtering tasks. The destroy() method signifies the end of service of the filter. The init() and destroy() methods of a portlet filter are called only once during their lifetime.

A single filter class can provide filter functionality for more than one life cycle method. Also, a single filter can provide filter functionality for more than one portlet. Multiple filters can be associated with one life cycle method of a portlet. The doFilter() method of a portlet filter might create customized request and response objects by using the RequestWrapper and ResponseWrapper classes and by passing these wrappers to the doFilter() method of the FilterChain object.

Note: A portlet filter is a Java technology-based component that can be used to modify the content of the portlet request and portlet response before or after any life cycle method of the portlet.


Click here to know How we can write a portlet filter?

Set cookies for portlet.

There you can set cookies for your portlet on the response of each lifecycle method (processAction, processEvent, render, and serveResource) with the following code:
response.addProperty(javax.servlet.http.Cookie cookie);

The cookie can then be accessed in all lifecycle methods using: request.getCookies(); method.