Exploiting the WebSphere Application Server V6.1 portlet container: Part 2: Going beyond the basics

Extend the capabilities of your applications

This article series examines the JSR 168 portlet container available in IBM WebSphere Application Server V6.1 and differentiates its use from WebSphere Portal.

Part 1 introduced the portlet container, including how to install a portlet, how to access the portlet, and how to use URL Addressability.

Part 2 illustrates some extended capabilities of the container including how to render a portlet within a window frame, how to display multiple portlets, how to get information about deployed portlets, and how to change the default portlet behaviour.

You can download example code and use it to see the features of the WebSphere Application Server V6.1 portlet container.

This series is for Java™ portlet programmers who are already familiar with the Java Portlet API. See Resources for links to information that can help you gain those skills.


Stephan Hesmer (stephan.hesmer@de.ibm.com), Performance Chief Developer, IBM

Stephan HesmerStephan Hesmer is currently working as Performance Chief Developer. In his previous role he worked as Portlet Runtime architect in WebSphere Portal and WebSphere Application Server. He is responsible for integrating the JSR 168 portlet container into WebSphere Application Server. Stephan worked on the JSR 168 Java™ Portlet Specification, and designed and implemented the initial version of the JSR 168 Reference Implementation, Pluto. Stephan received a Diploma of Information Technology from the University of Cooperative Education Stuttgart, Germany, in 2000. After graduating, he joined the IBM Böblingen Development Laboratory to work in the WebSphere Portal Team.

Birga Rick (brick@de.ibm.com), Portlet Runtime Technical Lead, IBM

Author photoBirga Rick is Technical Lead for WebSphere Application Server Portlet Runtime at the IBM Boeblingen Lab in Germany. In 2003, she was part of the team implementing the JSR168 Reference Implementation, Pluto. Following her work on JSR 168 within the WebSphere Portal development team, she integrated the Portlet Runtime into WebSphere Portal and WebSphere Application Server.

19 July 2006

Also available in Japanese


Today, portal users are accustomed to having multiple portlets on a page, and to seeing each portlet's content embedded within a window frame that provides control icons or links to change the portlet mode or window state. WebSphere Application Server V6.1 provides a set of extended features that you can use to customize portlets using URL Addressability and to create a simple portal framework.

To design a customized portal framework, you create a JSP. You reference a new JSP tag library to easily aggregate your portlets. This aggregation tag library enables you to render the portlet content within a window frame or to aggregate multiple portlets onto a page.

To manage portlets, a portal framework needs to know which portlets are available in the system. WebSphere Application Server V6.1 provides new Managed Beans (MBeans) for portlets and portlet applications. You can use these MBeans to access information from the deployment descriptor of any deployed portlet.

Portlet URL Addressablity supports HTML out-of-the-box. If you want to support other markups, you can use PortletDocumentFilters which enable you to easily add different markup support. Like servlet filters, they are called prior to a portlet to change its behavior or default output.

This article shows how to use the aggregation tag library to build your own portal framework, how to use the MBean API, and how to customize portlets to support additional markups. This article also covers how these features compare to similar functionality in WebSphere Portal so you know the differences and how to achieve the same result in either product.

About the sample

You can download the sample code for the examples described in this article so that you can refer to it as you read the article. The examples are based on the WorldClock portlet application that was discussed in Part 1 of this article series; it is included in the download section below for your convenience. For a detailed description of the WorldClock portlet, see this article "Converting the WorldClock portlet from the IBM Portlet API to the JSR 168 portlet API" (see Resources).

Aggregating multiple portlets

Portal frameworks can manage, organize, and arrange portlet content on portal pages. With URL Addressability, WebSphere Application Server provides the simplest way for a portal page to display a single portlet, without any icons or menu links. You can easily extend this functionality using a new Java Server Page tag library. This aggregation library provides a way to create a simple, customized portal framework that processes a portlet action and renders multiple portlets into window frames, providing portlet title and control links to change the portlet mode or window state.

The library contains two categories of tags:

  1. Portal tags define the portal context in which the portlets run.

    For example, this context defines the URL format for portlet URLs and how to handle portlet preferences. In contrast to servlets, portlets must always be rendered within the context of a portal framework.

    The init tag specifies the URL of the portal framework so that the portlet's URLs refer to the portal. You can also use additonal request parameters with the portal JSP to control the flow.

    portletURLPrefix="<portal URL>"
    portletURLSuffix="<portal specific URL suffix>"
    portletURLQueryParams="<portal specific query parameters">
  2. Portlet tags consist of a URL creation tag to create portlet links and a portlet invocation tag to retrieve the portlet content.

    Because portlets require a portal context, you must imbed these portlet tags into the portal init tag.

    • The state tag creates a URL string referencing a portlet with a specified state. The portal framework can use the returned URL to provide control links for the portlet. Each URL can reference a new portlet state by defining another portlet mode or window state.
      url="<portlet URL>"
      windowId="<portlet window identifier>"
      action="<whether this is an action URL: true|false>"
      portletMode="<portlet mode>"
      portletWindowState="<window state"
      var="<variable name for this portlet URL>"
      scope="<scope for var: page|request|session|application>">
      <urlParam name="<parameter name>" value="<parameter value>"/>
    • The insert tag invokes a portlet and retrieves the portlet content for a portlet state. You can use this tag to retrieve the portlet title that a portlet can dynamically specify during rendering.
      url="<portlet URL>"
      windowId="<portlet window identifier>"
      contentVar="<variable name for this portlet content>"
      contentScope="<scope for contentVar:
      titleVar="<variable name for the dynamic portlet title"/>
      titleScope="<scope for titleVar: page|request|session|application>">

      All portlet tags provide a portlet URL attribute that specifies the portlet context and portlet name. You can use additional attributes to specify more details, such as the window identifier.

      Some attributes of the portlet tags let you write the result into variables instead of writing directly to the output stream, which causes buffering because the content is stored temporarily into a string. Because buffering has an impact on performance, the use of this functionality is generally not recommended.

Portal frameworks often specify variables for portlet content to display dynamic portlet titles above the actual portlet output. Instead, you should Javascript as shown in the following example.


Let's step through an example portal JSP to see how to use the aggregation tag library. If you have not already done so, you might want to download the sample code so you can view it as you read through this description.

This example renders two portlets into window frames with control links for each portlet to change the portlet mode.

First, in the JSP header, reference the aggregation tag library and define a namespacing prefix.

<%@ taglib uri="http://ibm.com/portlet/aggregation" prefix="portlet" %>

This declaration makes the tag library known to the JSP so you can use all the aggregation tags.

Next, define the portal context of the aggregation framework using the init tag. Declare the URL used to access the portal JSP in the attribute portletURLPrefix.

<portlet:init portletURLPrefix="/sample/portal/">

A portal framework usually consists of a servlet, including a portal JSP; however, this example only uses a JSP. Therefore, in this case, you must define the JSP in the web.xml to have a valid portal URL that references the portal JSP. Portal URLs should not have endings such as .jsp.

<?xml version="1.0" encoding="UTF-8"?>
<web-app id="WebApp" version="2.4" xmlns="http://java.sun.com/xml/ns/j2ee"

You can now use several portlet tags within the init tag that specifies the portal context.

You can use normal JSP or HTML handling to get the portlet links and portlet content into a good looking design.

Wherever you place a portlet link on the page, you can create the corresponding portlet URL using the aggregation tag library state tag. The following JSP snippet shows how to create a link to the VIEW mode of the WorldClock Portlet.

<a href="<portlet:state url='worldclock/StdWorldClock' windowId='birga'

The windowId provides an identifier which makes this portlet unique. Then, you can put the same WorldClock Portlet on the page again using another windowId. The above link does not have any effect on portlets defining different window identifiers. Each portlet window must provide its own links.

<a href="<portlet:state url='worldclock/StdWorldClock' 
   windowId='stephan' portletMode='view'/>">view</a>

After designing the page layout with window frames and portlet control links for each portlet, insert the portlet content into the page, using the insert tag referencing the portlet URL and window identifier.

<portlet:insert url="worldclock/StdWorldClock" windowId="birga" 

By defining a variable for the dynamic title that is set by the portlet, you can use Javascript to embed the title into the window frame.

Listing 1 shows how the completed portal.jsp.

Listing 1.Portal.jsp using the aggregation tag library
<%@ taglib uri="http://ibm.com/portlet/aggregation" prefix="portlet" %>
<%@ page isELIgnored ="false"%>
<portlet:init portletURLPrefix="/sample/portal/">
<!-- create portal table of two columns -->
   <!-- insert portlet title bar into left column -->
   <TABLE WIDTH="100%">
          <B><span id="title_1">Portlet 1</span></B>
          <TD ALIGN="right">
            <a href="<portlet:state url='worldclock/StdWorldClock' 
				windowId='birga' portletMode='view'/>">view</a>
            <a href="<portlet:state url='worldclock/StdWorldClock' 
				windowId='birga' portletMode='edit'/>">edit</a>
            <a href="<portlet:state url='worldclock/StdWorldClock' 
				windowId='birga' portletMode='help'/>">help</a>
   <!-- insert portlet title bar into right column -->
   <TABLE WIDTH="100%">
          <B><span id="title_2">Portlet 2</span></B>
          <TD ALIGN="right">
            <a href="<portlet:state url='worldclock/StdWorldClock' 
				windowId='stephan' portletMode='view'/>">view</a>
            <a href="<portlet:state url='worldclock/StdWorldClock' 
				windowId='stephan' portletMode='edit'/>">edit</a>
            <a href="<portlet:state url='worldclock/StdWorldClock' 
				windowId='stephan' portletMode='help'/>">help</a>
<!-- insert portlet into left column -->
    <portlet:insert url="worldclock/StdWorldClock" 
		windowId="birga" titleVar="portlettitle_1"/>
<!-- insert portlet into right column -->
    <portlet:insert url="worldclock/StdWorldClock" 
		windowId="stephan" titleVar="portlettitle_2"/>
<!-- insert portlet title -->
<script type="text/javascript">
  document.getElementById("title_1").firstChild.nodeValue = "${portlettitle_1}";
  document.getElementById("title_2").firstChild.nodeValue = "${portlettitle_2}";

To see the example portal page (as shown in Figure 1):

  • Package and install the portal.jsp within a Web application.
  • Then, access the portal aggregation by opening this URL in your browser: http://localhost:9080/sample/portal
Figure 1. Example output of the portal aggregation JSP
Figure 1. Example output of the portal aggregation JSP

Comparing to WebSphere Portal

WebSphere Portal provides a sophisticated aggregation framework which you can customize with your own themes and skins. For example, in WebSphere Portal, you can apply fine-grained access control within the aggregation framework.

There is no functionality in WebSphere Portal corresponding to the aggregation tag library provided by the WebSphere Application Server V6.1 portlet container. The aggregation tag library lets you create a very simple portal framework to aggregate multiple portlets on a page; it is intended to be used by portlet development systems.

Accessing portlet information

A portal framework that creates a window frame around the portlet content often provides additional icons to support changes of portlet modes or window states. In order to display the correct icons, the portal framework must know which modes or states the portlet supports. For example, the portal needs to know if the portlet supports the edit mode before it can display an icon with a link to the edit mode of the portlet. Each portlet application provides such information through the portlet deployment descriptor. This information is accessible to MBeans.

Generally, all MBeans are made accessible to the AdminClient of the WebSphere Application Server. See the Developing an administrative client program section of the WebSphere Application InfoCenter (listed in Resources) to learn how to retrieve the AdminClient and how to use MBeans in general.

With the startup of a portlet application, the following portlet-specific MBeans are created:

  • One MBean of type PortletApplication for the portlet application defined within the portlet deployment descriptor.

    Its name consists of the name of the portlet application file concatenated with the suffix _portletapplication. For example:


  • One MBean of type Portlet for each portlet defined in the portlet application.

    Its name consists of the above PortletApplication MBean name concatenated with the portlet name as suffix. For example:


See the Mbean interfaces section of the WebSphere Application Server InfoCenter (listed in Resources) for the Javadoc describing the Portlet and PortletApplication MBeans .

There are several uses for the MBean API. A few examples are:

  • Retrieving access to all portlet applications and portlets available in the system so that a portal can list them and provide navigation or portlet management features.
  • Retrieving portlet titles so that a portal can display the title above the portlet content in a window frame which surrounds the portlet content.
  • Retrieving custom window states defined by the portlet so a portal can support them.
  • Retrieving all supported portlet modes by the portlet so that a portal might display only the appropriate control links.

A portal framework that wants to find out which control icons or links to provide for a portlet can retrieve a list of supported portlet modes for a specific content type. See the following code snippet on how this can be done for the StdWorldClock portlet and the content type text/html:

ObjectName on = new 
on = (ObjectName) adminService.queryNames(on, null).iterator().next();
HashMap contentTypes = (HashMap) adminService.getAttribute(on, "contentTypes");
List list = (List) contentTypes.get("text/html");

In addition to all the information provided by the portlet deployment descriptor, the PortletApplication MBean defines notification constants a portal can listen for by registering a NotificationListener. See the Developing an administrative client program section of the WebSphere Application InfoCenter (listed in Resources) to learn how to register and handle notification events.


This example shows one of several scenarios for which the portlet-specific MBeans can be used. It gathers information about all deployed portlets to provide a list of them on top of the portal aggregation. The user can select a portlet from this list which will then be displayed in the aggregation.

To gain general access to all MBeans in the system, retrieve the AdminClient:

Properties p = new Properties();
p.put("port", "8880");
p.put("host", "localhost");
p.put("type", "SOAP");
AdminClient adminService = AdminClientFactory.createAdminClient(p);

All portlet applications have MBeans registered of type PortletApplication. Therefore, you create an ObjectName pattern specifying the MBean type, which returns a list of all available PortletApplication MBeans in the system.

ObjectName paons = new ObjectName("WebSphere:type=PortletApplication,*");
Iterator iter = adminService.queryNames(paons, null) .iterator();
while (iter.hasNext()) {
    ObjectName paon = (ObjectName) iter.next();

Each portlet application provides access to a list of its portlets using the MBean attribute portletMBeanNames. To retrieve access to the MBeans, create an ObjectName pattern specifying the Portlet MBean name. It returns a list of all available MBeans of that name. (Although a list is returned, this list will never contain more than one entry.)

Iterator innerIter =  ((List) adminService.getAttribute(paon, 
while (innerIter.hasNext()) {
    String name = (String)innerIter.next();
    ObjectName pons = new ObjectName("WebSphere:name=" + name + ",*");
    ObjectName pon = (ObjectName) adminService.queryNames(pons, null).iterator().next();

Now that you have access to all portlet applications and portlets in the system, you can look for the information required to provide a drop-down list from which to select a portlet. This list contains portlet URLs for each available portlet.

When the portal uses the aggregation tag library to display a portlet, it needs to know the corresponding portlet URL. This URL consists of the web application context and the portlet name, such as worldclock/StdWorldClock.

The web application context is common for all portlets within one application, so you can retrieve it as an attribute of the PortletApplication MBean.

String context = (String) adminService.getAttribute(paon, "webApplicationContextRoot");

For the portlet name, access the attribute name of the Portlet MBean.

String portletName = (String) adminService.getAttribute(on, "name");

Finally, you need to adapt the portal aggregation to provide a list with all the portlet URLs so that the user can select a portlet. The portal.jsp then uses this selection to invoke the portlet in its aggregation.

Listing 2 shows the code to store all portlet urls into a bean gathered using Mbeans.

Listing 2. Storing the portlet URLS into the list
PortletListBean bean = new PortletListBean();
// add all available portlet URLs to PortletListBean
try {
    Iterator iter = adminService.queryNames(paons, null).iterator();
    while (iter.hasNext()) {
      ObjectName paon = (ObjectName) iter.next();
      String context = (String)
      Iterator innerIter = ((List)
        while (innerIter.hasNext()) {
          String name = (String)innerIter.next();
          ObjectName on = new ObjectName("WebSphere:name=" + name + ",*");
          on = (ObjectName) adminService.queryNames(on, null).iterator().next();
          String portletName = (String) adminService.getAttribute(on, "name");
          bean.addURL(context + "/" + portletName);
} catch (Exception e) {

Based on this bean, we create a selection list for all available portlets. After updating the portal.jsp, you can install and access the portal aggregation by using: http://localhost:9080/sample/portal

Figure 2. Portal aggregation providing a selection for all available portlets
Figure 2. Portal aggregation providing a selection for all available portlets

Comparing to WebSphere Portal

The MBean API to access portlet information is unique to WebSphere Application Server. In WebSphere Portal, there is no corresponding access to the portlet model publically available.

The requirement to retrieve information about available portlets in the system is mainly motivated by a portal framework. WebSphere Portal provides its own portlet deployment and object model to save and access all information about the portlets installed. Therefore, there is no need for WebSphere Portal to provide a public API based on this motivation.

Filtering portlets to modify output

When a portlet is directly addressed by a URL, the portlet output can be modified by filters, called PortletDocumentFilters, embedded into a filter chain. A pre-defined, default filter converts the portlet fragment output of the portlet into a valid document. In this way, portlets can be displayed in the browser as full documents like servlets.

The DefaultFilter, provided out-of-the-box, converts the portlet content into a simple valid HTML document. You can replace or extend it using customized PortletDocumentFilters.

PortletDocumentFilters are a normal servlet filters which implement javax.servlet.Filter and follow the servlet filter chain mechanism. The difference lies within the way you declare and deploying them.

Instead of specifying the filter directly in the web.xml, you register PortletDocumentFilters by an extension point in the plugin.xml, located in the root directory of the JAR file containing the PortletDocumentFilter .

<extension point=
     class-name="sample.WindowFrameFilter" order="1200" />

You can deploy a PortletDocumentFilter in two different ways:

  1. Add the filter JAR file to the lib directory of the Application Server. The JAR file has the following structure:
    • A plugin.xml in the root directory
    • The filter class file in the appropriate package directory within the JAR file
  2. Provide the filter as osgi bundle within the plugins directory of the Application Server. The JAR file has the following structure:
    • A plugin.xml in the root directory
    • The filter class file in the appropriate package directory within the JAR file
    • A MANIFEST.MF file that specifies bundle details in the META-INF directory.

The normal servlet filter concept does not provide any portlet support to developers who wish to create a PortletDocumentFilter. Therefore, there are two helpers provided for PortletDocumentFilters to implement portlet specific needs:

  • com.ibm.wsspi.portletcontainer.util.FilterRequestHelper
  • com.ibm.wsspi.portletcontainer.util.PortletURLHelper

The FilterRequestHelper provides easy access to control the filter flow. Behind the scene, request attributes transfer flow information. For example, the isDocument method verifies if an earlier filter has already converted the fragment into a document. Accordingly, each filter can specify special needs using the setRedirect and setDocumentmethods.

Important: The system does not useg these properties. Each filter must check for these properties before converting the markup so that a filter does not convert an already-converted document again into a document.

The PortletURLHelper analyzes a servlet request URL to identify portlet information according to the URL Addressability pattern. This way, the helper enables the filter to easily determine if a portlet action URL is requested or which portlet mode is called.

To support additional markups, such as WML, create new PortletDocumentFilter, register it, and then call it prior to the default HTML filter. The new filter must mark the document conversion by calling the setDocument method on the FilterRequestHelper. This marker prevents the DefaultFilter from converting the fragment into an HTML document. This way, you can use PortletDocumentFilters to add markup support, or to modify document output.


Portals usually render portlet content into window frames, providing links to different portlet modes and window states. When using URL Addressability, no window frame displays around the portlet content. In this example, you see how to add a simple window frame using a custom PortletDocumentFilter.

  1. First, create a new filter class, which implements javax.servlet.Filter, and name it WindowFrameFilter. The main method is the doFilter method.
    public class WindowFrameFilter implements Filter 
    public void init(FilterConfig config) throws ServletException {}
    public void doFilter(ServletRequest request, 
    ServletResponse response, 
    FilterChain chain)
    throws IOException, ServletException {
    public void destroy() {}
  2. In doFilter, analyze the URL to determine if the request meets the corresponding pre-requisites to add a window frame:
    • Verify whether the request is marked to indicate it has completed a document conversion. A valid document is required to add a window frame surrounding the portlet content. Therefore, you need to ignore the request if this is not the case.
      // do nothing if document cannot be found 
      if (!FilterRequestHelper.isDocument(request))
        chain.doFilter(request, response);
    • Depending on the diverse document filters in the system, it might be necessary to also add a check to see if the request document is an HTML document.
    • Check if the request url is an action URL to determine if you need to ignore this request as well. Use the PortletURLHelper for this check. If an InvalidURLException occurs, the filter must transfer this information to the HttpServletResponse, as shown below.
      // analyze request url
      HttpServletRequest servletRequest = (HttpServletRequest) request;
      HttpServletResponse servletResponse = (HttpServletResponse) response;
      String portleturl = null;
      try {
        PortletURLHelper urlHelper = new PortletURLHelper("","",servletRequest.getPathInfo());
        // do nothing if action called
        if (urlHelper.isAction()) 
           chain.doFilter(request, response);
        portleturl = createPortletURL(servletRequest, urlHelper);
      catch (InvalidURLException e) 
  3. If the request meets these prerequisites, you can embed the portlet content into a window frame. Create a simple HTML table to add a row of links above the portlet content.
    PrintWriter writer = response.getWriter();
    writer.println("<TABLE BORDER='5'>");
    writer.println("<TR BGCOLOR='BBBBFF'><TD>");
    writer.println("<TABLE WIDTH='100%'>");
    writer.println("<B><span id='portlet_title_1'>Portlet</span></B>");
    writer.println("<TD ALIGN='right'>");
    writer.println("<a href='" + portleturl + "/state=normal'>normal</a>");
    writer.println("<a href='" + portleturl + "/state=maximized'>maximized</a>");
    writer.println("<a href='" + portleturl + "/state=minimized'>minimized</a>");
    chain.doFilter(request, response);
  4. These links reference the different portlet window states. To create the portlet url links, you can use a base URL String referring to the portlet containing all required information according to the URL addressability pattern, so that only the varying window state information is missing.
    StringBuffer buffer = new StringBuffer();
    String portleturl = buffer.toString();
  5. Before seeing this window frame surrounding the portlet content, create a JAR file with plugin.xml for this WindowFrameFilter. This xml defines the filter location as well as the filter order. For this example, the filter order must have a value higher than 1000 to be called after the DefaultFilter because the window frame can only be created after the HTML document conversion is complete.
    <?xml version="1.0" encoding="UTF-8"?>
    <?eclipse version="3.0"?>
    <plugin id="portletwindowfilter" name="WS_Server" provider-name="IBM" version="1.0.0">
      <extension point="com.ibm.ws.portletcontainer.portlet-document-filter-config">
        <portlet-document-filter class-name="sample.WindowFrameFilter" order="1200" />
  6. To deploy the filter, place the filter JAR file into the lib directory of the Application Server, and restart the server.
  7. To accessing the WorldClock Portlet with this filter applied open this URL in a browser: http://localhost:9080/worldclock/StdWorldClock

    You see the results in Figure 3.

    Figure 3. Portlet filtered to provide a portlet window frame
    Figure 3. Portlet filtered to provide a portlet window frame

Comparing to WebSphere Portal

Portlet fragments can be modified by PortletDocumentFilters of the WebSphere Application Server. The corresponding feature provided by the WebSphere Portal is the PortletFilter concept.

WebSphere Portal provides its own filter mechanism for its PortletFilter mechanism; the PortletDocumentFilter is based on servlet filters. PortletFilters are embedded into a proprietary filter chain and implement a PortletFilter interface, which provides easy access to portlet specific needs. These filters are more flexible compared to PortletDocumentFilters. They do not require a server restart so that they can be dynamically enabled per portlet.


In this part of the article series, you looked deeper into the portlet container in WebSphere Application Server. You learned about the aggregation feature which helps create a simple portal framework. Then, you saw how to modify the portlet output when addressed by a URL, and how to locate and access portlet information. You saw how these features compare to features in WebSphere Portal and the differences in addressing portlets.

In the next part, you see more advanced features of the JSR 168 portlet container in WebSphere Application Server. You will learn how to manage the portlet container and portlets using wsadmin and the Admin Console, and how to retrieve information about portlet performance measurements.


Code samplesPortlet-container-p2-ex.zip30 KB
World clock portletStdWorldClock.war75 KB



developerWorks: Sign in

Required fields are indicated with an asterisk (*).

Need an IBM ID?
Forgot your IBM ID?

Forgot your password?
Change your password

By clicking Submit, you agree to the developerWorks terms of use.


The first time you sign into developerWorks, a profile is created for you. Information in your profile (your name, country/region, and company name) is displayed to the public and will accompany any content you post, unless you opt to hide your company name. You may update your IBM account at any time.

All information submitted is secure.

Choose your display name

The first time you sign in to developerWorks, a profile is created for you, so you need to choose a display name. Your display name accompanies the content you post on developerWorks.

Please choose a display name between 3-31 characters. Your display name must be unique in the developerWorks community and should not be your email address for privacy reasons.

Required fields are indicated with an asterisk (*).

(Must be between 3 – 31 characters.)

By clicking Submit, you agree to the developerWorks terms of use.


All information submitted is secure.

Dig deeper into WebSphere on developerWorks

ArticleTitle=Exploiting the WebSphere Application Server V6.1 portlet container: Part 2: Going beyond the basics