Known issues and restrictions with portlet communication

Known issues and restrictions with portlet communication

+
Search Tips | Advanced Search

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 classloader. Use basic Java types, such as java.lang.String or java.util.HashMap for compound data. Custom classes must be installed in a shared library available to both portlets or must be directly installed into the directory profile_root/PortalServer/config.
JSR 286 events with XML bindings allow you to transfer complex data types between portlets in different classloaders. However, to avoid the performance penalty incurred by XML serialization, follow the recommendations above.
When you import sample Struts WAR files including the file pbstrutsExample.war into Rational Application Developer Version 6, it reports broken links. You can ignore this warning message.
Rational Application Developer 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. You can ignore them in the Click-to-Action WSDL resources.
To prevent these warning messages from being displayed...

Go to...
Window | Preferences | Workbench | Capabilities | Web Service Developer

...and ensure that Web Services Development is selected.
Click Apply.
Select...
Window | Preferences | Web Services | WS-I Compliance

Set the compliance levels to Ignore compliance.
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 you create 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 by using older versions of Rational Application Developer Version 6 can contain code that does not work with WebSphere Portal v6.1.5. 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 above, wires between IBM portlets might also not apply to a user who has personalized the source or target portlet. In this case, that user needs to explicitly recreate 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 by 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. ExampleFigure 1. 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);
      }
    catch (ClassCastException e)// should not happen, as this class should 
                                // be provided only if the app portlet 
                                // implements PortletTitleListener
    {
      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 top of 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 as shown below in order 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 topic:
Portlet communication

Related concepts

Shared portlet state
Publish/subscribe message based communication
Special purpose techniques for data exchange
Cooperative portlets
Event broker
Portlet wires
Public render parameters
Struts Portlet Framework
Portlet events
Interoperability between events and cooperative portlets
Web Services Description Language (WSDL) 1.1
XML Schema Part 2: Datatypes Second Edition