Compare JSR 168 v/s IBM Portlet API

This section gives a high level comparison between the new JSR 168 Portlet API and the IBM Portlet API. First, it covers the concepts that are similar; then, it explains some of the differences between the two.


The following concepts are very similar in JSR 168 and the IBM Portlet API.

Feature Similarities Differences
Portlet modesBoth support the basic portlet modes: Edit, Help, and View.The config mode is optional in the JSR 168. The other optional JSR 168 modes (About, Edit_defaults, Preview, Print) are not supported by the IBM Portlet API.
Window statesThese window states are supported: Maximized, Normal, and Minimized.The Solo window state is only supported by the IBM Portlet API.
Portlet lifecycleThe lifecycle life cycle is the same: init, process requests, destroy.none
Request processingRequest processing is divided into an action phase for processing user actions and a render phase for producing the markup. none
URL encodingBoth support creating URLs pointing to the portlet or to a resource.none
Include servlets/JSPsServlets and JSPs can be included in the portlet.none
Portlet sessionPortlets can store transient information that should span requests in a session.none
Portlet application packagingBoth package portlet applications as WAR files with an additional deployment descriptor called portlet.xml.The portlet.xml format differs.
Expiration-based cachingThe portlet can support expiration based caching.The APIs use different mechanisms to implement this functionality.
The IBM Portlet API uses a polling mechanism where the portal queries the portlet for how long the markup will be valid, whereas in the JSR 168 the portlet can attach an expiration time to each created markup. Sharing the cache entry across users is only possible in the IBM Portlet API.


The JSR 168 and the IBM Portlet API differ in the following ways.

Feature IBM Portlet API JSR 168
Portlet application entitiesLets you define an abstract portlet application and different instance of this portlet application as concrete portlet applications via the deployment descriptor. This allows reusing settings of the abstract portlet application and only overwriting the parts that are unique for each concrete portlet application. The deployment descriptor follows the web.xml deployment descriptor and defines one portlet application and the portlet definitions for this application.
Portlet entityThere is one portlet object instance per portlet configuration in the Web deployment descriptor. There may be many PortletSettings objects parameterizing the same portlet object according to the Flyweight pattern, provided on a per-request basis. Changes in the PortletSettings apply to all portlet instances of this concrete portlet. The user can also have personal views of concrete portlets that are rendered using the PortletData for customization of the output. PortletSettings and PortletData are merged into one object called PortletPreferences.
Request/Response objectsThe request/response object that the portlet receives in the render call is the same as the one received in the action call. In the JSR 168 these are two different objects.

Exclusive to JSR 168

These items are only available in the JSR 168.

Feature Description
Render parametersRender parameters allow the portlet to store its navigational state.
Render parameters stay the same for subsequent render requests and only change when the portlet receives a new action. This enables bookmarkability and solves the browser back button problem.
Global HttpSession scopePortlets can store data not only with the visibility of the portlet, but also with the visibility of the whole Web application.
RedirectPortlets can redirect to other Web resources in the action phase.

Exclusive to the IBM Portlet API

The following concepts are only available in the IBM Portlet API.

Feature Description
EventingEvents can be sent between portlets.
Additional lifecycle listenersLifecycle listeners besides action and render, (such as begin page) are not available in the first version of the JSR 168.
Portlet menusLets the portlet contribute content to a menu bar to facilitate navigation through portal pages.
Invalidation based cachingLets the portlet explicitly invalidate cached content.