The Portlet Container for WebSphere Liberty is a JSR 168 and JSR 286 compliant runtime environment for portlet applications. This article summarises the operational differences between the Liberty version of the portlet container and the implementation used in WebSphere Application Server full profile.
The Portlet Container for WebSphere Liberty is used to develop and test your portlet applications with a lightweight and fast web application runtime.
Although portlet applications written against the Portlet Container for Liberty can be deployed without any changes to the full profile, there are some notable differences when it comes to configuration and supported features. These can be categorized into two main groups: Technical differences because of the underlying web application runtime and discontinued features.
The following article describes the current state as of January 2015. Like every other software product, details might be subject to change in future releases.
Technical differences in the Portlet Container
Separation of Portlet Container and Portlet Serving
Unlike the Portlet Container plug-in in the WebSphere Application Server full profile, the Portlet Container feature for Liberty does not come with a portlet serving functionality. Portlet serving is sometimes also referred as URL addressability.
The portlet serving-specific part of the original container were moved into a separate feature called Portlet Serving. This reduces the footprint of a Liberty setup which only aims to serve as a Portlet Container backend. There is no additional configuration needed to explicitly restrict access to deployed portlets via URL addressability.
The Portlet Serving feature depends on the Portlet Container feature, therefore if URL addressability is desired, both features have to be installed. Enabling the Portlet Serving feature will cause Liberty to automatically enable the Portlet Container feature.
To use the serving functionality, use your web browser to request a web site with the web application context root of your portlet application followed by a slash and the respective portlet name.
The Portlet Container and Portlet Serving features support portlet modes as described by JSR 168 (and JSR 286). By default, these modes are
Help. The Portlet Serving feature uses a URL-based approach to specify a specific mode. For instance, you can use
http://host:port/ContextRoot/DashboardPortlet/default/ver=2.0/mode=edit to display a portlet named
You should always keep in mind that enabling the Portlet Serving feature gives direct access to the deployed portlets. Therefore, it is only recommended to use this feature in a development environment or in proof-of-concept scenarios. Using it in production systems poses a certain security risk due to the direct URL addressability.
Class and package visibility
Liberty provides an OSGi environment and, therefore, all features and web or portlet applications are bound to the rules of the OSGi bundle visibility. The Portlet Container and Portlet Serving feature extend the OSGi environment with additional bundles.
Each bundle has its very own set of visibility rules for specific Java packages. For example, all implementation-specific classes are hidden from web or portlet applications. Only
SPI classes are accessible.
Portlet applications that depend on direct access to implementation classes will fail to start with a
java.lang.NoClassDefFoundError. A complete list of exported packages is listed in the Subsystem Manifest of the Portlet Container feature:
Global portlet filters
IBM WebSphere Application Server supports the usage of an Eclipse-based extension API. Developers use this API by providing a
plugin.xml with their web application. Inside this plug-in configuration file, a number of extension points register custom code for various purposes.
Historically, the portlet container offers two types of extension points to incorporate additional functionality in to the runtime: collaborators and global portlet filters. Global portlet filters are similar to portlet filters. In contrast to them, global filters are independent of a web application and apply to all portlets registered in the container. There are four types of portlet filters:
ResourceFilter. Collaborators are only configurable in the full profile and will not be discussed here.
In general, using global portlet filters can cause performance or stability risks, because of their universal and generic nature. All requests for the Portlet Container trigger custom global portlet filters for each portlet application that is deployed. Therefore, coding issues in these filters have an obvious effect on the overall functionality of your applications. Unless there are is no other way, avoid this type of extension mechanism.
Liberty does not have Eclipse extension point support. These kind of modifications and preferences were moved into the server configuration, which is mostly done in the
server.xml file of the respective Liberty server instance. The runtime ignores any
plugin.xml files that might be shipped in portlet applications (WAR files). The Portlet Container feature extends the Liberty server configuration with an additional section called
You may add entries inside this configuration section to configure custom global portlet filters. The configuration is based on the settings that were used in the
plugin.xml files; for instance, for each entry you have to specify the implementation class of the respective interface.
In contrast to the full profile, in Liberty you have to exactly specify the location of the container (JAR file) that stores the implementation class. This way you can be sure that exactly the version of the filter is instantiated that is configured by you. The standard Liberty Shared Library reference approach is used to specify the location of the classes.
The configuration of portlet filters for a specific portlet application using the respective
portlet.xml file remains as it was in the full profile.
Unavailable exception and web container servlet destroy behavior
The web container used in WebSphere Liberty does have a slightly different behavior when it comes to the processing of a
javax.servlet.UnavailableException. These can be the result of a
javax.portlet.UnavailableException, which is translated to a
javax.servlet.UnavailableException in the Portlet Servlet of the Portlet Container.
For the most usage scenarios of the Portlet Container this does not have any impact on the portlet application. However, if you choose to be fully JSR 286 compliant, you need to specify a special web container setting. For all Liberty runtimes from version 220.127.116.11, set
true in the Web Container configuration setting of your
For Liberty versions 18.104.22.168 and 22.214.171.124, install APAR PM98245 manually in order to have this configuration setting.
Without the APAR, as a workaround set
false in order to force the web container to destroy a servlet. Not installing the APAR and using this workaround is not recommended and only noted here for the sake of completeness.
Discontinued features in the Portlet Container
Remote Request Dispatcher
Remote Request Dispatcher (RRD) functionality is not available the Liberty Portlet Container. This technology is now obsolete with support of Web Services for Remote Portlets (WSRP). In order to achieve a scalable solution of remote/external request processing, download and set up a Liberty-based WSRP Producer which serves content for a WSRP Consumer like WebSphere Portal Server.
Portlet Container for WebSphere Liberty does not support configuration for fragment caching of portlet application content. Although there might be minor benefits of caching at this level, it is recommended to implement caching in upper layers of the respective applications.
Performance Monitoring Infrastructure
Support for the Performance Monitoring Infrastructure (PMI) in Liberty is not yet available.
WebSphere extension files
The current version of the Liberty-based Portlet Container feature does not support web application-based special configuration instructions via the
ibm-portlet-ext.xmi file. This includes configuration for
portletServingEnabled settings. To disable portlet serving functionality, remove the Portlet Serving feature from the list of features in your
Portlet Aggregation Tag Library
There is no support for Portlet Container-based portlet aggregation via a tag library. Like the Web Container for servlets, the main mission of the Portlet Container is to serve as a runtime processing unit for portlets. Aggregation and composition of any kind should be done via frameworks and stacked products like the WebSphere Portal Server that have well-elaborated features for user management, security, scalability, caching, and many more.
The support for collaborators to extend the Portlet Container runtime is not available in the Liberty Portlet Container. Analogous to the global portlet filters, this kind of extension causes performance and stability risks to the server runtime and is not recommended anyway.