Troubleshooting portlet development

This section contains information that can assist you in preventing, identifying, and correcting problems related to WebSphere Portal. For information related to specific components, see the appropriate troubleshooting topic.

 

JDBC Business Object Builder error after testing Cloudscape datasource connection

Before creating a new JDBC business object using the JDBC Business Object Builder, test the datasource connection in WebSphere Application Server. If the database tested is Cloudscape, the JBDC Business Object Builder portlet displays only Ok and Cancel when you try to create a business object in the portlet.

If you are using Cloudscape, stop and restart all application servers after testing the datasource connection in WebSphere Application Server. After the applications servers have started, JDBC Business Object Builder displays the options necessary for building a business object.

 

Debugging the Tivoli Access Manager Login Module

To debug the Tivoli Access Manager supplied PDLoginModule added to WebSphere Portal portallogin.config, add debug=true to the end of the specification of the login module. 

com.ibm.websphere.security.auth.module.proxy.WSLoginModuleProxy
    required delegate=com.tivoli.mts.PDLoginModule debug=true;

The output is written to standard out for the Portal Server Application Server.

 

Install WAR file fails when file name is too long

Solution: Because Windows limits the maximum path length to 260 characters, the name of the WAR file must be less than approximately 25 characters. Installing a WAR file with a name that is more than 25 characters can result in longer pathnames which makes the files not accessible anymore resulting in FileNotFoundExceptions. The Portal tries to truncate or rename long names before it deploys the WAR file into Application Server. However it cannot always circumvent the pathname to exceed the limit. To correct this error, modify the file name to be less than 25 characters. It is recommended that you install WebSphere products into the root directory to keep the common part of pathname short. For example, install to c:\WebSphere instead of c:\Program Files\WebSphere.

 

Login command customization fails

When creating your own implementation of one of the WebSphere Portal classes, for example, Login or Logout modules, update WebSphere Application Server so that the classes load correctly.

  1. Open the Administrative Console for WebSphere Application Server.
  2. Click Environment Then click Shared Libraries Then click WPSlib.
  3. Add your JAR file to Classpath.
  4. Click Ok.
  5. Click Save to save the changes to the master configuration.
  6. Restart the WebSphere_Portal application server.

 

Cannot deploy portlets using the WebSphere Portal test environment

In the test environment, WebSphere Studio Application Developer and Portal Toolkit can be installed by a computer administrator and used by a domain user. The administrator is able to deploy portlets, but the domain user is not. This error occurs because the stack trace in the wpstimestamp.log under the studio_root\runtimes\portal_v50\log contains the following error: 

  com.ibm.wps.pe.mgr.exceptions.InitException: PEAS0009E: Failed to get WPS SOAP port

This error can be present because the workplace that is being used is under the administrative directory, c:\documents and settings\administrator\application data\ or c:\documents and settings\administrator\local settings. This workplace cannot be correctly accessed by the domain user.

Delete this workspace and create a new one, such as c:\workspace, that everyone can access correctly.

 

JSP files do not compile with the xerces.jar file in the portlet

In some cases, JSP files from custom portlets do not compile in WebSphere Portal Version 5.02 when using the xerces.jar file in your portlets. When this problem occurs, the following error message is displayed. 

2004.02.13 15:36:27.734 E com.ibm.wps.pe.pc.legacy.impl.PortletContextImpl include
javax.servlet.ServletException: Unable to compile class for JSP
at com.ibm.ws.webcontainer.jsp.servlet.JspServlet$JspServletWrapper.service(JspServlet.java:422)
at com.ibm.ws.webcontainer.jsp.servlet.JspServlet.serviceJspFile(JspServlet.java:675)
at com.ibm.ws.webcontainer.jsp.servlet.JspServlet.service(JspServlet.java:773)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:853)
at com.ibm.ws.webcontainer.servlet.StrictServletInstance.doService(StrictServletInstance.java:110)
at com.ibm.ws.webcontainer.servlet.StrictLifecycleServlet._service(StrictLifecycleServlet.java:174)
at com.ibm.ws.webcontainer.servlet.IdleServletState.service(StrictLifecycleServlet

To resolve this problem, apply fix PQ77263, which you can find at http://www-1.ibm.com/support/docview.wss?uid=swg24005598

 

Cannot share session data between Web applications

In WebSphere Portal Version 5.0.2, portlets cannot share data through the session with each other. This is because with WebSphere Application Server Version 5, the J2EE specification states that web applications cannot share session data. This J2EE specification also applies to setting data into the session from a custom log in or any portlets in a different web application.

To work around this, use either a database update or a singleton with a hashmap that contains your data.

See also