Consult the table below for some common problems and their solutions.
Refer to the readme file for Rational® tools. It is available from the Start menu (in Windows®) or from the installation launchpad for the Rational Software Development Platform.
Problems | Solutions |
---|---|
Cannot start WebSphere® Portal v5.x Test Environment |
|
Cannot create a server for the WebSphere Portal v5.x test environment. |
|
When testing on a WebSphere Portal 5.1.0.0 test environment, the following error occurs: com.ibm.websphere.wmm.exception.InvalidMemberDNException: The syntax of the member DN <admin_user_id> is invalid. Check if the special characters are escaped. | The administrator user ID defined for the Target Server must be the same as the one used for the Portal test environment install. |
JSP or Java compilation errors occur for imported, exported, or deployed portal | JSP files or Java classes that rely on external JAR files
for some classes may fail to compile if any of these conditions occur:
This can occur because the import, export and deploy operations do not affect the referenced JAR files. To resolve this problem, if your
Portal project uses external JAR files, the JAR files need to be made available
to the server.
|
java.lang.NoClassDefFoundError in the WebSphere Portal v5.x Test Environment. | When you test or debug a portlet application using local debugging and the portlet application needs to use library files or refer to other projects, you will need to make them available to the server. Refer to the section on Shared libraries in Defining local servers for testing portlets or Referring to other projects. |
The transcoding function does not work correctly when running or debugging portlets on a WebSphere Portal v5.0 Test Environment server. | The transcoding function is disabled in the WebSphere Portal v5.0 Test Environment by default. You need to enable it. Refer to Enabling transcoding. |
Cannot launch the WML device emulator using the WebSphere Portal v5.0 Test Environment. | To run or debug portlets in a WML device emulator using the WebSphere Portal v5.0 Test Environment, you need to enable transcoding. Refer to Enabling transcoding. You also need to define your device emulator program using the instructions in Defining Web browsers and device emulators. |
Cannot run personalized portlet projects in the WebSphere Portal v5.x Test Environment. | To run or debug personalized portlet projects you need to use WebSphere Portal Server Attach and WebSphere Portal running on a remote server. |
Faces portlets that contain utility *.jar files used by EJB snippet support fail at run time on a remote WebSphere portal server. | This happens during when deploying these portlets as
part of a new portal project to a Portal server. For more information, refer to Testing and deploying portlets that reference J2EE modules. |
Performing Run on Server on a portlet that is being used in a portal project yields an unexpected EAR file in the Server Selection dialog. | Instead of selecting the portlet project, select the
portlet's EAR project and right-click to perform the Run on Server function. To
find the portlet project's EAR file
|
Could not restore workbench error when starting the Rational Software Development Platform. | Restart Rational tools and specify a new directory
as the workspace. If you selected Use this workspace as the default and
do not show this dialog box again before and the dialog to allow you to
specify the workspace directory does not appear, start the workbench with
the -data parameter. From the command line:cd workbench_installdir rationalsdp.exe -data workspace_directory cd workbench_installdir rationalsdp.sh -data workspace_directory where workbench_installdir is the directory where you have installed Rational Software Development Platform and workspace_directory is the new workspace directory you want to use |
Portlets developed for WebSphere Portal 4.2 do not work correctly on WebSphere Portal 5.x. | This solution works only when the portlets were developed
by Portal Toolkit 5.0.2 or earlier. To fix this, do one of the following:
Most portlets written for WebSphere Portal Version 4.2 will run unchanged in WebSphere Portal Version 5.x. Some of the Portlet API 4.2.x are now marked as deprecated, but are still available on WebSphere Portal Version 5.x. However, the portlet.tld file is different between versions of WebSphere Portal. This file was included in portlet projects in Portal Toolkit 5.0.2 or earlier. |
Running (testing) or debugging a portlet in the test environment failed. After launching the Run on Server or Debug on Server task, the test environment was in starting state, but it terminated. The portlet has no validation errors in JSP files or Java code, and the deployment descriptor is correct. | Ensure Build automatically is selected in Workbench Preferences. To check the value, select . |
Portlet deployment or testing on a remote system failed.
The failure can occur with any of these tasks:
|
Ensure that the server is configured correctly. See Network considerations. |
The contents in the Console view are truncated when running or debugging a project on a WebSphere Portal v5.x Test Environment server. | Ensure that Limit console output is not selected in Workbench Preferences. To check the value, select . |
The WebSphere Portal v5.1 Test Environment does not start when two or more JSR 168 portlet projects are associated with it. | The WebSphere Portal v5.1 Test Environment fails to start when two or more JSR 168 portlet projects are associated with the server and they do not have the ID attribute on the <portlet-app> element in the portlet deployment descriptor. The same problem can occur if the ID attribute is not unique. To solve this problem, edit the portlet deployment descriptor (portlet.xml) and add an ID attribute with a unique value to the <portlet-app> element. Make the change using the Source page when editing the portlet deployment descriptor. |
The deployment of a JSR 168 portlet project to a WebSphere Portal v5.0 server works only once. | Using the WebSphere Portal administrative pages on the WebSphere Portal server, remove (uninstall) the JSR 168 portlets you want to deploy, apply the fix PQ92087 to your portal server, then deploy your portlets again using Rational Software Development Platform. |
When importing a portlet WAR file, no WebSphere Portal servers appear in the Target server list. | Check the DOCTYPE entry of the Web
deployment descriptor (web.xml) in the WEB-INF directory
of the WAR file. The correct syntax is: <!DOCTYPE web-app PUBLIC "-//Sun Microsystems, Inc.//DTD Web Application 2.2//EN" "http://java.sun.com/j2ee/dtds/web-app_2_2.dtd">where the string web-app_2_2.dtd defines the Web level of the WAR file. The string web-app_2_2.dtd is for Web level 2.2 ( J2EE specification level 1.2). The string web-app_2_3.dtd is for Web level 2.3 ( J2EE specification level 1.3). A common mistake is to have a "." instead of a "_" character in the version number. For instance, web-app_2.2.dtd instead of web-app_2_2.dtd. If you have not imported
the WAR file, follow these steps to correct the problem:
If you have already imported the WAR file, follow these steps
to correct the problem:
|
Portlets that contain J2EE dependencies (i.e. database connections, EJB and dependent utility JAR projects) do not deploy to a remote Portal server with either portlet or portal projects. | For more information, refer to Testing and deploying portlets that reference J2EE modules and Referring to other projects |
Deploy or export of a portal project fails. Part of the error message indicates a DuplicateKeyException for the primary key constraint defined on PAGE_INST(OID) . |
When an object is deleted from a WebSphere Portal v5.1 server, the object is marked as deleted but is not immediately removed. If the object is then exported or deployed to the remote portal server attach server, a duplicate object ID error can occur. This problem can occur
in the following scenarios:
To resolve this problem, you can either configure WebSphere Portal to remove objects immediately, or run an individual cleanup task using the XML configuration interface. For instructions, see the WebSphere Portal Product Documentation section in the |
Caching of labels and pages When running a WebSphere Portal v5.1 portal project on a remote server attach server, changes to the structure of labels and pages do not appear immediately. |
WebSphere Portal v5.1 servers cache the contents of pages. When you run a portal project on a remote server, you may not see changes to the contents of pages for up to 10 minutes, which is the default lifetime of the cache. To change the cache lifetime, change the value of the cacheinstance.com.ibm.wps.model.content.impl.ResourceCache.lifetime parameter in the Portal_installation_directory/shared/app/config/services/CacheManagerService.properties file on the remote portal server. The value is the number of seconds that the cache is kept. The values 0 or -1 mean there is no timeout. If you change the structure of labels and pages and the changes do not appear in your Web browser, explicitly log out of WebSphere Portal using the Web browser and log back in. After the login, the changes will be shown. Note that closing the Web browser window may not work. The log out and log in steps need to be performed every time an updated portal project is published. |
On some configurations using WebSphere Portal v5.0, changes made to a portal or portlet project do not show up automatically in the Web browser when running or debugging the project using a remote Server Attach server. | There are two ways to deal with this:
|
Server connection failure when debugging on either a test environment or remote server. | If you cannot attach to a test environment or remote portal server for debugging, and you are sure that the server is properly configured, then the problem may be caused by a timeout when connecting to the JVM process on the remote machine. This can happen if the remote machine is busy or if your network is slow. You can increase the default timeout value of three (3) for debugging by selecting Debugger timeout field to ten (10) seconds. , and increasing the value of the |
Cooperative portlets are not performed by the built-in browser (Konqueror) of SuSE Linux Enterprise Server version 9. | For more information, including a list of Web browsers that support the cooperative portlet menus, refer to the topic in the WebSphere Portal information center.For instructions on defining an alternative Web browser, see Defining Web browsers and device emulators. |
Portal projects with wires between IBM® portlet API portlets fail to deploy or export to WebSphere Portal 5.1.0.0. | Refer to the deployment prerequisite instructions in Wiring cooperative portlets. |
Wires deleted from an imported WebSphere Portal server are still available on the remote portal server, after deployment. | You can only remove wires from a WebSphere Portal server that has being updated with iFix PK00815. |
If you have upgraded your portal server from 5.0.2 through 5.0.2.1 to 5.0.2.2, and are using DB2® V7.2 with Fixpack 7 or Fixpack 8, you may encounter the error message Character reference "#26" is an invalid XML character when importing a portal project from the portal server. This is due to a problem in updating the portal server from 5.0.2 to 5.0.2.1, and results in corrupt double-byte characters in the portal database that are not valid in XMLAccess. | To fix this problem you will need to manually run
two XMLAccess scripts against the server. Follow these steps:
|