Portal, V6.1

---

 

Known issues and restrictions with portlet communication

The following known issues and restrictions exist 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 classloader. Use basic Java types, such as java.lang.String or java.util.HashMap for compound data. Custom classes must be installed in a WAS shared library available to both portlets or must be directly installed into the directory portal_server_root/shared/app.

  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 V6, 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, follow these steps:

  1. Select Window, then Preferences, then Workbench, and then Capabilities.

  2. Expand Web Service Developer and ensure that Web Services Development is selected.

  3. Click Apply.

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

  5. Set the compliance levels to Ignore compliance.

  6. 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. If this occurs, replace the file jsf-portlet.jar in the failing WAR file with the version in the latest fix pack level.

 

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;">
  

 

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

 

Related reference

Portlet events
Interoperability between events and cooperative portlets

Web Services Description Language (WSDL) 1.1

XML Schema Part 2: Datatypes Second Edition

---