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.
- 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 java.lang.String or java.util.HashMap for
compound data. 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_root/PortalServer/config. Note: JSR 286 events with XML bindings allow you 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. 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:
- Select Window, then Preferences, then Workbench, and then Capabilities.
- Expand Web Service Developer and ensure that Web Services Development is selected.
- Click Apply.
- Select Window, then Preferences, then Web Services, and then WS-I Compliance.
- Set the compliance levels to Ignore compliance.
- Click Apply.
Important: 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 IBM WebSphere Portal Express® Version 8.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 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.
For example: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:
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="<%=onClickMarkup%>">
<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.