The Java Portlet Specification 2.0 added the concept of Portlet Filters, to allow for code to be called on portlet initialization, destruction and action, event and render phases, so that developers could intercept portlet requests and insert additional functionality to existing portlets (eg, for common mechanisms across portlets like auditing or a hit counter) similar to what has been available to J2EE developers via Servlet Filters for quite a while now.
For more information about JSR286 Java Portlet Specification 2.0 Portlet Filters and other mechanisms new to the 2.0 portlet spec, see the following article:
A sample portlet filter
The following Java class ( com.ibm.samples.MyPortletFilter ) implements the JSR286 RenderFilter interface.
For this sample, it just does a debug println to stdout, which will go to the Portal's SystemOut.log file, for each of the filter methods that are called by the portlet container.
* Licensed Materials - Property of IBM
* Copyright 2009. IBM Corporation. All rights reserved.
* US Government Users Restricted Rights - Use, duplication or disclosure restricted by GSA ADP Schedule Contract with IBM Corp.
* The Program may contain sample source code or programs, which illustrate
* programming techniques. You may only copy, modify, and distribute these
* samples internally. These samples have not been tested under all conditions
* and are provided to you by IBM without obligation of support of any kind.
* IBM PROVIDES THESE SAMPLES "AS IS" SUBJECT TO ANY STATUTORY WARRANTIES THAT
* CANNOT BE EXCLUDED. IBM MAKES NO WARRANTIES OR CONDITIONS, EITHER EXPRESS OR
* IMPLIED, INCLUDING BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OR CONDITIONS OF
* MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE, AND NON-INFRINGEMENT
* REGARDING THESE SAMPLES OR TECHNICAL SUPPORT, IF ANY.
public class MyPortletFilter implements RenderFilter
public void doFilter(RenderRequest req, RenderResponse res, FilterChain chain)
throws IOException, PortletException
System.out.println("DEBUG: My Portlet Filter Pre-processing a render request"); //\$NON-NLS-1\$
// Hand off control to the next filter in the chain, or the portlet itself if no more filters
System.out.println("DEBUG: My Portlet Filter Post-processing a render request"); //\$NON-NLS-1\$
public void destroy()
System.out.println("DEBUG: Destroying My Portlet :-("); //\$NON-NLS-1\$
public void init(FilterConfig arg0) throws PortletException
System.out.println("DEBUG: Initializing My Portlet"); //\$NON-NLS-1\$
Configuring a portlet filter
The Java Portlet Specification 2.0 defines optional elements to define portlet filters, and then to map them to portlets (via portlet name) also defined in the descriptor.
WPF generates the WEB-INF/portlet.xml descriptor each time you publish a portlet WAR from a project, from a template under WEB-INF/bin/deploy ment. To avoid upgrade issues, WPF recommends not editing the portlet.xml template directly, but rather to use the new deployment descriptor fragment processing mechanism available as of the August 09 WPF Next beta update and followon WPF releases.
The fragment processing mechanism allows you to add elements to standard web and portlet deployment descriptors, by defining a subset of a descriptor in one of the WEB-INF/bin/deployment/extensions folders. For instance, see the readme in your project's WebContent/WEB-INF/bin/deployment/extensions/portlet.jsr286/Readme.txt
The following filter fragment file (MyPortletFilter.xml) should be placed under your project's WebContent/WEB-INF/bin/deployment/extensions/portlet.jsr286 folder.
The following debug statements were sent to the SystemOut.log when the portlet application, and then the portlet, was initialized and rendered.
The lines in bold were printed by the sample portlet filter code shown above, while the other lines were logged by WAS and WP as the application was initialized, used and stopped.
When I stopped the application via the WebSphere Admin Console, the portlet filter's destroy method was called, as can be seen in the log with the "Destroying My Portlet :-(" entry that shows up shortly after the Admin Consoles log entry stating that my "tvp" application is being stopped.
[8/12/09 17:23:16:907 EDT] 0000004d ServletWrappe I SRVE0242I: [tvp] [/tvp] [/factory/util/fingerprint.jsp]: Initialization successful.
[8/12/09 17:23:37:423 EDT] 0000004d ServletWrappe I SRVE0242I: [tvp] [/tvp] [WPFHelloPortletWorld]: Initialization successful.
[8/ 12/09 17:23:37:657 EDT] 0000004d SystemOut O DEBUG: Initializing My Portlet
[8/12/09 17:23:37:657 EDT] 0000004d SystemOut O DEBUG: My Portlet Filter Pre-processing a render request
[8/12/09 17:23:39:392 EDT] 0000004d ServletWrappe I SRVE0242I: [tvp] [/tvp] [/genjsp/HelloPortletWorld_page1.jsp]: Initialization successful.
[8/12/09 17:23:39:423 EDT] 0000004d SystemOut O DEBUG: My Portlet Filter Post-processing a render request
[8/12/09 17:26:07:111 EDT] 00000131 ApplicationMg A WSVR0217I: Stopping application: tvp
[8/12/09 17:26:07:174 EDT] 00000131 SystemOut O DEBUG: Destroying My Portlet :-(
[8/12/09 17:26:07:174 EDT] 00000131 ServletWrappe I SRVE0253I: [tvp] [/tv p] [WPFHelloPortletWorld]: Destroy successful.
[8/12/09 17:26:07:190 EDT] 00000131 ServletWrappe I SRVE0253I: [tvp] [/tvp] [J2EEDeploymentHandler]: Destroy successful.
[8/12/09 17:26:07:205 EDT] 00000131 ServletWrappe I SRVE0253I: [tvp] [/tvp] [AxisServlet]: Destroy successful.
[8/12/09 17:26:07:205 EDT] 00000131 ServletWrappe I SRVE0253I: [tvp] [/tvp] [/genjsp/HelloPortletWorld_page1.jsp]: Destroy successful.
[8/12/09 17:26:07:221 EDT] 00000131 ServletWrappe I SRVE0253I: [tvp] [/tvp] [/factory/util/fingerprint.jsp]: Destroy successful.
[8/12/09 17:26:07:236 EDT] 00000131 ServletWrappe I SRVE0253I: [tvp] [/tvp] [WebEngineServlet]: Destroy successful.
[8/12/09 17:26:07:471 EDT] 00000131 ApplicationMg A WSVR02 20I: Application stopped: tvp
Portlet Filters and Smart Refresh and Partial Page Refresh AJAX requests
Assuming you're using a recent version (eg, 7.0.x or later) of Web Experience Factory with JSR286 then Smart Refresh and Partial Page Refresh Ajax requests (as described in the JSR286 developerWorks article referred to above) use a JSR286 Resource Request which should also be able to go through such a filter if you configure it to do so via the lifecycle config in the portlet.xml (as described by the JSR286 specification). In other words, you are likely going to get Resource Requests (not just Action and Render Requests) if you use Web Experience Factory Smart Refresh and/or Partial Page Refresh. According to the JSR286 spec, the lifecycle phase name for a resource request, for such config should be RESOURCE_PHASE.