Known issues and restrictions with portlet communication

• The pop-up menu functionality requires browsers with JavaScript on the client.

• Complex Java types can only be transferred between portlets if they are deployed in a shared class loader.

  Use basic Java types, such as for compound data...

  java.lang.String
  java.util.HashMap

  Custom classes must be installed in a IBM WebSphere Application Server shared library available to both portlets or must be directly installed into the directory...

  WP_PROFILE/PortalServer/config

  JSR 286 events with XML bindings allow us to transfer complex data types between portlets in different class loaders. However, to avoid the performance penalty incurred by XML serialization, follow the previous recommendations.

• When you import sample Struts WAR files including the file...
  pbstrutsExample.war

  ...into Rational Application Developer Version 6, it reports broken links.

  We can ignore this warning message.

• RAD lists WS-I warnings for wsdl:binding errors.

  WS-I compliance warning messages will be displayed in the Problems view for Click-to-Action enabled portlets.

  We can ignore them in the Click-to-Action WSDL resources.

  To prevent these warning messages from being displayed...

  1. Select
     Window | Preferences | Workbench | Capabilities | Web Service Developer | Web Services Development | Apply

  2. Select Window, then Preferences, then Web Services, and then WS-I Compliance.

  3. Set the compliance levels to Ignore compliance.

  4. Click Apply.

  To remove the compliance warnings from the Problems view open the project's pop-up menu in the Project Explorer and select Run Validation.

• If multiple cross-page wires marked with the switch page flag are triggered at the same time, all wire targets are invoked.

  However, the target page to which a user gets directed cannot be predicted unambiguously.

• Cross-page wires for standard portlets are executed before redirecting to the target page.

  Therefore cross-page target portlets must not assume that they are executed on the target page.

• Wires created on a root page do not apply to derived pages that created by referencing the root page.

  While such pages do inherit the content of the original page, this inheritance does not apply to wires; you have to explicitly create the wires for the derived page.

• Cooperative Java Server Faces (JSF) portlets that you developed using older versions of RAD Version 6 can contain code that does not work with IBM WebSphere Portal v8.0.

  If this occurs, replace the file jsf-portlet.jar in the failing WAR file with the version in the latest fix pack level.

• Cooperative portlet action declarations with multiple input parameters configured in the WSDL file are not supported.

Issues and restrictions related only to IBM portlets

• In addition to the derived page restriction, wires between IBM portlets might also not apply to a user who has personalized the source or target portlet.

  In this cases that user needs to explicitly re-create the wire as a personal wire.

• Cooperative IBM portlets do not support anonymous users.

  This means that for portlets on a page to be able to transfer properties, the user must be logged in.

• When you invoke cross-page wires between cooperative portlets that do not have the switch page flag set, the target portlet action does not get invoked until the user manually navigates to the target page.

  This behavior is different from JSR 168 cross-page wires where the target action is immediately executed. If the user logs off before navigating to the target page of the wire, the action is not delivered at all.

• Cooperative portlets cannot use the getPortletSettings(), getServletConfig(), getServletContext(), getServletInfo() methods on the Portlet class and the getPortletLog() method on the PortletAdapter class. These objects can be retrieved by storing them during Portlet initialization or using the PortletRequest object for the current request.

• Cooperative portlets that need to implement the doTitle() method of the IBM portlet API must follow some additional steps.

  This is because the wrapper portlet for cooperative portlets does not implement PortletTitleListener to prevent the container from always calling each cooperative portlet's doTitle() method, regardless of whether the portlet implements PortletTitleListener.

  If the portlet needs to implement doTitle(), it must extend the base PortletWrapper class, implement PortletTitleListener in the extension, and use this as the wrapper class in web.xml.

  For example:

  Implementing doTitle()

  package com.myco.mywrapper;
  import org.apache.jetspeed.portlet.*;
  
  public class MyPortletWrapper extends com.ibm.wps.pb.wrapper.PortletWrapper 
                                implements PortletTitleListener
  {
    Portlet appPortlet_ = null;
  
    public void doTitle(PortletRequest request, PortletResponse response) 
                                       throws PortletException, IOException
    {
      Portlet appPortlet_ = getApplicationPortlet();
      try
      {
        ((PortletTitleListener)appPortlet_).doTitle(request, response);
      }
      // should not happen, as this class should 
      // be provided only if the app portlet 
      // implements PortletTitleListener
      catch (ClassCastException e)
      {
        response.getWriter().print(request.getPortletSettings().getTitle(request.getLocale(), request.getClient()));
      }
    }                      
  }
  
  

  To specify the new wrapper portlet in the web.xml, change the standard wrapper for cooperative portlets...

     <servlet-class>com.ibm.wps.pb.wrapper.PortletWrapper</servlet-class>
  

  ...to the new wrapper class...

     <servlet-class>com.myco.mywrapper.MyPortletWrapper</servlet-class>
  

• Click-to-action menus show action names instead of caption keys if the portlet does not provide a resource file for the language.

  For example, if the portlet provides a resource file for de, menus will display the correct caption as long as if the portal default language setting is de or the user's browser setting is de. However, if the user's browser setting is changed to en, the portlet C2A menus will not show the English caption (an English caption has not been provided) nor even the caption key, but the actual name of the action.

  The solution is for the portlet to provide a resource file for the language.

• To use Click-to-Action popup menus on <AREA> tags placed on an image map, accessibility enhancements must be disabled in order to have the menu render in the correct place.

  For example, if in a JSP file the variable "onClickMarkup" represents the markup returned by the property broker for the onClick action, then the JSP will have a line that looks like this:

  <AREA shape="circle" coords="1,2" onClick="<%=onClickMarkup%>">
  

  This line needs to be changed to disable these accessibility changes and bind the rendering of the menu to the location of the cursor:

  <AREA shape="circle" coords="1,2" 
        onClick="window.c2a_bind_to_cursor=true;<%=onClickMarkup%>window.c2a_bind_to_cursor=false;">
  

• Programmatic declaration of cooperative portlet actions and properties can lead to orphan wire definitions and problems creating wires.

  In staging scenarios, make sure that all legacy cooperative actions and properties have been initialized before creating wires for them.

Parent: Portlet communication
Related: Shared portlet state
Publish/subscribe message based communication
Special purpose techniques for data exchange
Portlet events based communications
Cooperative portlets
Interoperability between events and cooperative portlets
Event broker
Portlet wires
Public render parameters