© Copyright International Business Machines Corporation 2006. All rights reserved. US Government Users Restricted Rights - Use, duplication or disclosure restricted by GSA ADP Schedule Contract with IBM® Corp.
When importing a sample Portal project or creating a portal project using the "New Portal Project" wizard from the samples Gallery, a broken link warning message appears in the Problems view.
In this version of Rational® Developer, Portal Designer only supports displays in HTML, cHTML, and WML. If you have specified other supported markup languages for a page or label in an imported project, these markup languages are supported for display by Rational Developer but they cannot be edited. These markup languages will not be displayed in the Properties view.
Unless you assign a color palette to a page, the default color palette is used in WebSphere® Portal 6. However, in Portal Designer, when the color palette is not specified, the color palette of the ancestor page is used instead of the default palette.
In the New Portal Project wizard, selecting a portal server version does not automatically update the target runtime. The portal server version and target runtime settings must be manually synchronized. For example, you must select WebSphere Portal v6.0 runtime for a portal server version of 6.0.0.x, and you must select WebSphere Portal v5.1 runtime for portal server version of 5.1.0.x. If the target runtime version is not synchronized with the portal version, the portal server can become corrupted or unusable when the portal project is deployed.
In WebSphere Portal v6.0, when editing the CSS content type JSP files, such as styles.jsp or styles_theme.jspf, with a Styles dialog, JSP expressions may be displayed on the dialog. These JSP expressions cannot be modified on the dialog, you must modify them in the CSS Designer source panel.
For a JSR168 Faces portlet, if you use any of the following tools to generate a service client in a Faces JSP, the generated page code will not work correctly either on WebSphere Portal 6.0 or 5.1. The affected tools include:
- Page Data view
- Java™ Bean (with method invocation)
- Web Service
- EJB Session Bean
- Palette view
- Java Bean (with method invocation)
- Web Service
- EJB Session Bean
- Insert -> Data from either Page Designer context menu or windows menu
- Java Bean (with method invocation)
- Web Service
- EJB Session Bean
This is caused by the new implementation of JSR168 Faces portlet runtime contained in jsf-portletbridge.jar, which is different than before.
In the new implementation, pagecode beans for Faces JSPs, when declared as request-scope managed beans, do not persist between the portlet's Action phase and Render phase. In the generated Web Services client code, the pagecode bean is being used to cache the result of the web service during the Action phase. But since it's in the request scope, a new instance is created during the Render phase. Therefore the cached result is lost.
There are two possible solutions:
- Put the bean in session scope (this is configured in faces-config.xml). This is as simple as changing one line in the config file.
- This is not as simple as #1, but it is the preferred way of implementing services client in JSR168 portlets. It follows the best practices of JSR168 portlets programming and enables much better Back Button and bookmarking support.
- If there is a need to invoke the web service during the Action phase, for instance depending on service result different target page will be navigated, then you need to change the way the result is cached. Instead of using a local variable in the pagecode bean, use either the render parameter or the portlet session. Using render parameters is the preferred way to pass information from Action phase to Render phase, although it only supports String values. If the result is of a complex type, then you must use portlet session instead.
- Here is a sample snippet for setting values to render parameters from within JSF action method in the pagecode bean:
PortletResponse response = (PortletResponse)getFacesContext().getExternalContext().getResponse();
((ActionResponse)response).setRenderParameter("resultValue", resultValue);
- Here is a sample snippet for setting values to portlet session from within JSF action method in the pagecode bean:
PortletRequest request = (PortletRequest)getFacesContext().getExternalContext().getRequest();
request.getPortletSession().put("resultValue", resultValue);
- Or, if invoking the service during Action phase is not required, you can defer the service invocation to the getter method for the web service result bean. In JSF action method, put the input value in a render request parameter if it's a String, or portlet session if the input value is of a complex type. Then retrieve it from the getter method for the web service result bean, so it can be used to invoke the service.
- Here is a sample snippet for setting the input value in a render parameter within JSF action method in the pagecode bean:
PortletResponse response = (PortletResponse)getFacesContext().getExternalContext().getResponse();
((ActionResponse)response).setRenderParameter("inputValue", inputValue);
- Here is a sample snippet for retrieving the input value within getter method for the result:
PortletRequest request = (PortletRequest)getFacesContext().getExternalContext().getRequest();
String inputValue = request.getParameter("inputValue");
- Note that using render parameter to pass information to the render phase has the additional benefit of better browser Back button support and bookmarking support.
When importing a portal project you can get a question message box: "The following workspace files are inconsistent with the editor. Update the editor with the workspace contents". Click Yes.
The portlet app id is optional according to the JSR 168 specification but Rational® Developer does not publish portlets without ids correctly. Rational Developer does not generate portlets without these ids. It is possible that a portlet is created if you import a portlet from another source. To work around this problem, open the portlet deployment descriptor for the project and add a portlet application id in the source tab. For example:
<portlet-app xmlns=... version=... xmlns:xsi=... xsi:schemaLocation=... id="ENTER_YOUR_ID_HERE">
...
</portlet-app>
if the server state is detected as Stopped when the server is running, first ensure that your SOAP/RMI connector ports are correct and that the WebSphere security credentials you are using are correct in the server editor. If they are not correct, then the server state will never be detected as Started. If they are correct and the server state remains Stopped, then there may be a problem with WebSphere Application Server v6.1 and WebSphere Portal v6.0 co-existence.
The most common scenario is that you have the WebSphere Application Server 6.1 server installed on your local machine and you start with a new workspace. In this new workspace a WebSphere Application Server 6.1 server instance will be automatically created and initialized and this will prevent the Portal 6.0 state detection from working correctly. It can also happen if you just create a WebSphere Application Server v6.1 server and then create a Portal 6.0 server.
The solution is to restart your Rational product with the same workspace. The Portal 6.0 server instance should then work correctly as long as the WebSphere Application Server 6.1 server is not initialized i.e. its state remains blank instead of Stopped or Started.
Portlets do not display in pages after running or deploying my portal project to Portal 6.0. To minimize the effect of this issue, use configuration only deployment whenever full deployment is not necessary.
If you do encounter the problem, then try running a configuration-only deployment of the portal project without deploying any portlets. This usually enables the portal to render the portlets correctly again.
If you are creating a new Business Process Message and your WSDL file is in Document-Literal style then the input and output message names may not be displayed in the second page of the wizard. You are still able to select them and view the message details in the right-side of the wizard. The generated code will be correct despite the fact that the message names are not shown in the wizard.
If you are using the cooperative wizard to create source or target portlets and your JSR 168 portlet project contains multiple portlet types, such as one basic portlet and one struts portlet, the default action parameter in the wizard may be incorrect.
In basic and faces portlets, the default action parameter should be ACTION_NAME_PARAM, but the user may select a different value.
In struts, the action parameter must be spf_strutsAction.
These are the default values for the unique name in the task page containers:
WebSphere Portal v6.0: ibm.portal.MyTasks
WebSphere Portal v5.1: wps.MyTasksIn Portal Designer, when you use another page with a different unique name than those listed above, the page is not recognized as a task page container page in WebSphere Portal after deployment.
Workaround: After deployment, change the value of the TaskPageContainerUniqueName parameter in the My Tasks portlet using these steps:
1. Open Administration > Portlet Management > Portlets
2. For the My Tasks portlet, click Configure portlet button
3. For the TaskPageContainerUniqueName parameter, click Edit.
4. Change the value to the new unique name in Portal Designer using these values:WebSphere Portal v6.0: ibm.portal.MyTasks
WebSphere Portal v5.1: wps.MyTasks
5. Click OK.
If a portal project was migrated from Rational Developer 6.x into Rational Developer 7.0 workspace, it may cause deployment failure with a NoModuleFileException. When this happens, follow the procedure below to correct the problem.
- This procedure assumes that a "wps" EAR project has already been generated from the failed portal project deployment operation.
- Open the application.xml in the newly generated wps EAR project.
- Ensure the contents of the application.xml looks like the following:
<module id="WebModule_1163447032109">
<web>
<web-uri>wps.war</web-uri>
<context-root>wps</context-root>
</web>
</module>
<module id="WebModule_WSRP">
<web>
<web-uri>wps_facade.war</web-uri>
<context-root>/wsrp</context-root>
</web>
</module>
<module id="EjbModule_1">
<ejb>wp.scheduler.ejb.jar</ejb>
</module>
<security-role id="SecurityRole_1">
<description>Everyone in the enterprise.</description>
<role-name>Everyone Role</role-name>
</security-role>
<security-role id="SecurityRole_2">
<description>All Authenticated users in the enterprise.</description>
<role-name>All Role</role-name>
</security-role>
<security-role id="SecurityRole_3">
<description>No users in the enterprise.</description>
<role-name>No Role</role-name>
</security-role>
- More specifically, the contents should
- contain a web module definition for wps.war with content-root value set to "wps".
- not contain more than one web module definitions with content-root value set to "wps".
- contain a web module definition for wps_facade.war with content-root value set to "/wsrp.
- contain an ejb module definition for wp.scheduler.ejb.jar.
- contain security role definitions for "Everyone Role", "All Role" and "No Role".
- Save and re-publish again.
Due to an outdated version of jsf-ibm.jar that was shipped in WebSphere Portal 6.0, some JSF components do not render correctly in portlets if the classloader mode is set to PARENT_FIRST on portlet web module. This is because when the classloader mode is set to PARENT_FIRST, then the jsf-ibm.jar in WebSphere Portal 6.0 will be used instead of the copy contained in the portlet web module.
Only the components in the jsf-ibm.jar, which correspond to uri http://www.ibm.com/jsf/html_extended, are affected. Both Faces IBM portlets and Faces JSR168 portlets are affected.
The classloader mode of the portlet web module will be set to PARENT_FIRST under the following situations, therefore would need to be changed:
To workaround this problem, open the application.xml file in the EAR project containing the portlet project, and open the "Deployment" tab. In the "Application" section please find the tree displaying the EAR and the portlet project. Select the portlet project, and change the "Classloader mode" from "PARENT_FIRST" to "PARENT_LAST". You may need to publish the application again for the change to take effect on the target server.
- when the portlet is deployed by Rational Developer v7.
- when the portlet is first installed in WebSphere Application Server using the EAR, then configured in WebSphere Portal using xmlAccess command.
If the portlet is installed directly in WebSphere Portal using the WAR, either in WebSphere Portal administration page or using xmlAccess command, then the classloader mode is already set to PARENT_LAST. In this case the portlet will work correctly without any workaround.
When a portal project 5.1.0.1 created using Rational Developer 6.x is imported with Project Interchange into a Rational Developer 7.0 workspace, "Run on WebSphere Portal v5.1 Test Environment" may fail.
Workaround: Modify the contents of the .portalsettings file using these steps:
1. Open Window > Open Perspective > Other... .
2. Select Resource and click OK in the Open Perspective dialog.
3. Expand the portal project in the Navigator view.
4. Select the .portalsettings file and open with Text Editor.
5. Insert the following.
<?xml version="1.0" encoding="UTF-8"?>
<portalSettings>
<portal-version version="5.1.0.1"/>
<portlets-ear-project portlets-ear-project-name=""/>
<process-integration mytaskspage-uniquename="wps.MyTasks"/>
</portalSettings>
The capability "Web Developer (advanced) needs to be turned on to view the Import Portal wizard and the portal and portlet samples (from the Samples Gallery). To enable the capability go to Help > Welcome, in the Welcome click on the button "Enable Roles" which is located in the corner of the screen. Then select role "Web Developer (advanced)" to turn it on. Re-start the wizard or Samples Gallery for the changes to take effect.