IBM WebSphere Portal version 6.1 or higher is installed successfully, however during the startup of the server, users are unable to access the login page and receive an error of 404: Page Not Found. The SystemOut.log file shows an error message of EJPFD0016E: Initialization of service failure while the Portal appserver was starting. This Technote explains how to resolve this error so users can successfully access the portal's login page.
Content
Actions Taken to Induce Behavior
1) Login to the WebSphere Application Sever Administrative console for the WebSphere_Portal
server (i.e. http://hostname:10027/ibm/console by default).
2) Navigate to Troubleshooting -> Runtime Messages -> Runtime Warning
3) Select Warning from the pull down menu and click apply.
4) Review and Save the changes.
5) Restart the WebSphere Portal server.
*Note: This behavior will only be induced if logging into the Application Server Administrative console that is running in the WebSphere_Portal application server, for example:
http://hostname:10027/ibm/console
It will not be induced if logging into the Application Server Administrative console that is running in the server1 application server, for example:
https://hostname:10003/ibm/console.
Look in the serverindex.xml file to confirm which WC_adminhost_secure port numbers are being used for server1 and WebSphere_Portal.
Review of the Portal SystemOut.log File
The file SystemOut.log records many activities that the portal undertakes during
startup and runtime. Reviewing this file, the following might be observed:
[4/21/09 17:49:27:438] 00000014 Servlet E com.ibm.wps.engine.Servlet init EJPFD0016E:
Initialization of service failed.
Caused by: java.lang.ClassNotFoundException: com.ibm.wps.services.ServiceHelper
[4/21/09 17:49:27:486] 00000014 ServletWrappe E Deregister the mbean because of uncaught init()
exception thrown by servlet portal: javax.servlet.UnavailableException: Initialization of one or more
services failed.
Caused by: java.lang.NoClassDefFoundError: com.ibm.wps.services.ServiceHelper
Resolving the Errors
1) Locate the following file:
/wp_profile/config/cells/
2) Make a backup of this file.
3) Open this file in an ASCII text editor
4) Locate the following line in the server.xml file:
5) Add the following line JUST after this line in the server.xml file:
required="false"/>
*Be SURE the xmi:id= does NOT match any other items in this file.
6) Save the server.xml file.
7) Stop and start the Portal server.
APAR Fix Available
WebSphere Application Server (WAS) APAR PK79875 will prevent this behavior from occurring. This APAR is scheduled for inclusion in the WAS 6.1.0.25 and 7.0.0.5 fixpacks. If runtime warning messages are required in the affected environment, it is STRONGLY recommend the interim APAR fix be installed to prevent the ws.ext.dirs property from being overwritten.
Technical Explanation: Missing Java .jar File During Startup
WebSphere Portal is dependent on correctly loading a number of Java .jar files during startup to
correctly function. In this instance, the NoClassDefFoundError indicates the Portal system is either using
an incorrect Java classloader to load the .jar file, or, is unable to locate a .jar file needed for proper
operation.
Reviewing the Portal SystemOut.log file, the following may be observed during a previous startup
attempt:
ws.ext.dirs = /opt/IBM/WebSphere/PortalExpress/AppServer/java/lib:[...]:/opt/IBM/WebSphere
/PortalExpress/AppServer/deploytool/itp/plugins/com.ibm.etools.ejbdeploy/runtime:/opt/IBM
/WebSphere/PortalExpress/PortalServer/shared/ext
Reviewing the Portal SystemOut.log file, the following may be observed during a current startup attempt:
ws.ext.dirs = /opt/IBM/WebSphere/PortalExpress/AppServer/java/lib:[...]:/opt/IBM/WebSphere
/PortalExpress/AppServer/deploytool/itp/plugins/com.ibm.etools.ejbdeploy/runtime
Observe the missing /opt/IBM/WebSphere/PortalExpress/PortalServer/shared/ext value in the ws.ext.dirs parameter. This parameter is built from the WebSphere Portal server.xml file. The actions taken section caused an update to occur to the WebSphere Portal server.xml file. This update inadvertently overwrote the property which specified the ws.ext.dirs parameter.