Known issues and restrictions with portlet communication

Review this information for a list of known issues and restrictions with portlet communication.

The following known issues and restrictions exist with portlet communication.

  • 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 IBM WebSphere Portal v7.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 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 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 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.
        Example

        Figure 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, verify all legacy cooperative actions and properties have been initialized before creating wires for them.


    Parent

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

     


    +

    Search Tips   |   Advanced Search