Friday Jul 11, 2008

Container Runtime Options

I just stumbled upon this article on The author has nicely explained "container runtime option" feature of Portlet 2.0 specification. During the draft phase of Portlet 2.0 specification, OpenPortal Portlet Container team blogged on many of JSR 286 features on PortalPost. You can find about all the new features in this blog.

Coming back to the TSS article, the good point to note is that author has used OpenPortal portlet container to explore Portlet 2.0 features. If you are associated with Portlet technology since beginning, you might be knowing that Pluto used to be de-facto container for JSR 168 portlet development. But, after open sourcing of Sun's portlet container implementation and hosting it as sub project of OpenPortal at, it has gained lot of momentum. Here are the things that I like about OpenPortal portlet container:

1. Fully compliant JSR 286 implementation
2. Easy installation on Glassfish and Tomcat.
3. Easy  deployment/un-deployment of Portlets
4. Good tooling support for Netbeans and Eclipse.
5. Last but not least, OpenSource and FREE :)

The author at TSS has provided link for download page of App Platform SDK, which is a GF + Portlet Container + WSRP bundle. If you already have Glassfish install, you can download Portlet Container 2.0 binary and deploy it on GF in secs. So, happy portlet writing.

Tuesday Aug 28, 2007

JSR 286 : Portlet filter feature

One of the major new feature added in the Portlet technology by the JSR 286 is the Portlet Filter. A portlet filter is a Java component that can be used to modify portlet request and response before/after any lifecycle method of the portlet is being executed. The concept of Portlet filter is same as that of servlet filter. The only difference is that a servlet has only one request handling method i.e. service() method and therefore there is only one type of the servlet filter. A portlet has four types of request handling methods and therefore there are 4 different types of portlet filters. The portlet API defines following interfaces for creating Portlet filter:

javax.portlet.filter.ResourceFilter (for serveResource method)

javax.portlet.filter.RenderFilter (for render method)

javax.portlet.filter.ActionFilter (for processAction method)

javax.portlet.filter.EventFilter (for processEvent 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, doFilter() method in ActionFilter takes ActionRequest and ActionResponse while doFilter() method of RenderFilter takes RenderRequest and RenderResponse objects. Each of the above filter interface extends a common base interface called javax.portlet.filter.PortletFilter. This common base interface contains init(javax.portlet.filter.FilterConfig filterConfig) and destroy() methods. 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 init() and destroy() methods of a portlet filter are being called only once during their lifetime.

A single filter class can provide filter functionality for more than one lifecycle methods and also a single filter can provide filter functionality for more than one portlet. There can be multiple filter associated with one lifecycle method of a portlet. The javax.portlet.filter.FilterChain class (created by Portlet container) is used to invoke the sequence of filters applicable for a particular lifecycle method of a portlet. The doFilter() method of a portlet filter may create customized request and response objects by using \*RequestWrapper and \*ResponseWrapper classes and passing these wrappers to the doFilter() method of FilterChain.

In order to write a portlet filter, the developer is required to do the folowing 2 things :

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 is also required to override init() and destroy() method of javax.portlet.filter.PortletFilter interface.

2) Add entry of filter in portlet.xml - After writing a portlet filter class, it can be configured by adding following 2 xml fragements in portlet.xml.








<value>Filter 1 - portlet-container 2.0 Filter demo :)</value>







The first xml fragment defines a filter by providing a logical name to it. It tell portlet container about the filter class and the lifecycle phases supported by it. You can specify initialization parameters also.

The Second xml fragment specifies the portlet(s) for which this filter will be applicable. You can specify a single portlet name or mapping to a group of portlets using the ‘\*’ as a wildcard.

Wednesday Mar 14, 2007

Difference between Java Application Platform SDK and Java EE SDK

Inder has described this nicely in his blog. I am trying to summarize it as : 

JavaEE5 SDK : JavaEE5 implementation (aka Glassfish) + API doc + tutorial + Blueprints + Samples

Java Application Platform SDK : JavaEE5 SDK + PortletContainer + JWDP (it is not JWSDP) + Open ESB + Access Manager

Wednesday Feb 28, 2007

What is new in JSR 286

If you are familiar with Portlet 1.0 and wants to know what is new in Portlet 2.0, here is a summary of new features. This information is based on first draft available here and may change in final draft.

1. Portlet eventing or Inter Portlet Communication (IPC) - Portlet 1.0 have very limited capability of eventing within same portlet application using application session scope. JSR 286 will allow coordination between different portlets across different portlet applications deployed in same portlet container. A new lifecycle phase called processEvent() has been introduced between processAction() and render() phase. New classes such as EventRequest and EventResponse has been added for this purpose.

2. Shared Render Parameters - This is another addition to enhance coordination among portlets within same portlet application.

3. Shared Session Attributes -  to share user data among different portlets in different portlet applications (in other words, sharing of  data on portal level for a given user)

4. Portlet Filter - Similar to servlet filters, this will allow dynamic interception of requests and responses to transform or use the information contained in the portlet requests or portlet responses. While servlet has only one "Filter" interface, portlet have one "\*Filter" interface corresponding to each lifecycle method of portlet.

5. Resource Serving - Provides the ability for a portlet to serve a resource. A new called RESOURCE_SERVING_PHASE has been added for this purpose.

6. Support for Ajax - Similar to IPC and web framework bridges, the support for Ajax in different implementation of Portlet 1.0 is vendor specific. Portlet 2.0 is trying to make a standard for Ajax support.

7. Serving markup fragements - Portlet 2.0 is trying to provide support for an usecase where a fragement of the markup will be returned by the portlet. This will be helpful in providing support for technologies like AJAX.

8. Alignment with WSRP 2.0 - Web Services for Remote Portlet (WSRP) 2.0 specification from OASIS is also in the draft stage and Porltet 2.0 EG is trying to align these 2 specification.

9. Better support for web frameworks - Portlet 2.0 is trying to provide additional means for creating bridge for web frameworks such as JSF, struts, spring etc. Currently these bridges are proprietary for different portal vendors and Portlet 2.0 is trying to make these bridges portable.




« August 2016