This section provides some debugging tips for resolving common Java 2 Platform
Enterprise Edition (J2EE) application client problems. To use this troubleshooting guide, review the trace entries for one of the J2EE application client exceptions,
and then locate the exception in the guide. Some of the errors in the guide are samples, and the actual error you receive can be different than what is shown here. You might find it useful to rerun the launchClient command specifying the -CCverbose=true option. This option provides additional information when the J2EE application client run time is initializing.
Error: java.lang.NoClassDefFoundError
| Explanation | This exception is thrown when Java code cannot load the specified class. |
| Possible causes |
|
| Recommended response | Check to determine if the specified class exists in a Java Archive (JAR) file within your Enterprise Archive (EAR)
file. If it does, make sure the path for the class is correct. For example,
if you get the exception: java.lang.NoClassDefFoundError: WebSphereSamples.HelloEJB.HelloHomeverify that the HelloHome class exists in one of the JAR files in your EAR file. If it exists, verify that the path for the class is WebSphereSamples.HelloEJB. If both the class and path are correct, then it is a class path issue. Most likely, you do not have the failing class JAR file specified in the client JAR file manifest. To verify this situation...
If you have multiple JAR files to enter in the Classpath field, be sure to separate the JAR names with spaces. If you still have the problem, you have a situation where a class is loaded from the file system instead of the EAR file. This error is difficult to debug because the offending class is not the one specified in the exception. Instead, another class is loaded from the file system before the one specified in the exception. To correct this error, review the class paths specified with the -CCclasspath option and the class paths configured with the Application Client Resource Configuration Tool. Look for classes that also exist in the EAR file. You must resolve the situation where one of the classes is found on the file system instead of in the .ear file. Remove entries from the classpaths, or include the .jar files and classes in the .ear file instead of referencing them from the file system. If you use the -CCclasspath parameter or resource classpaths in the Application Client Resource Configuration Tool, and you have configured multiple JAR files or classes, verify they are separated with the correct character for your operating system. Unlike the Classpath field, these class path fields use platform-specific separator characters, usually a colon (on UNIX platforms) or a semi-colon (on Windows systems). Note: The system class path is not used by the Application Client run time if you use the launchClient batch or shell files. In this case, the system class path would not cause this problem. However, if you load the launchClient class directly, you do have to search through the system class path as well. |
Error: com.ibm.websphere.naming.CannotInstantiateObjectException: Exception occurred while attempting to get an instance of the object for the specified reference object. [Root exception is javax.naming.NameNotFoundException: xxxxxxxxxx]
| Explanation | This exception occurs when you perform a lookup on an object that is not installed on the host server.
Your program can look up the name in the local client Java Naming and Directory Interface (JNDI) name space, but received a NameNotFoundException exception because it is not located on the host server. One typical example is looking up an EJB component that is not installed on the host server that you access.
This exception might also occur if the JNDI name you configured in your Application
Client module does not match the actual JNDI name of the resource on the host server. |
| Possible causes |
|
| Recommended response | If you are accessing the wrong host server, run the launchClient command again with the -CCBootstrapHost parameter specifying the correct host server name. If you are accessing the correct host server, use the product dumpnamespace command line tool to see a listing of the host server JNDI name space. If you do not see the failing object name, the resource is either not installed on the host server or the appropriate application server is not started. If you determine the resource is already installed and started, your JNDI name in your client application does not match the global JNDI name on the host server. Use the Application Server Toolkit to compare the JNDI bindings value of the failing object name in the client application to the JNDI bindings value of the object in the host server application. The values must match. |
Error: javax.naming.ServiceUnavailableException: A communication failure occurred while attempting to obtain an initial context using the provider url: "iiop://[invalidhostname]". Make sure that the host and port information is correct and that the server identified by the provider URL is a running name server. If no port number is specified, the default port number 2809 is used. Other possible causes include the network environment or workstation network configuration. Root exception is org.omg.CORBA.INTERNAL: JORB0050E: In Profile.getIPAddress(), InetAddress.getByName[invalidhostname] threw an UnknownHostException. minor code: 4942F5B6 completed: Maybe
| Explanation | This exception occurs when you specify an invalid host server name. |
| Possible causes |
|
| Recommended response | Run the launchClient command again and specify the correct name of your host server with the -CCBootstrapHost parameter. |
Error: javax.naming.CommunicationException: Could not obtain an initial context due to a communication failure. Since no provider URL was specified, either the bootrap host and port of an existing ORB was used, or a new ORB instance was created and initialized with the default bootstrap host of "localhost" and the default bootstrap port of 2809. Make sure the ORB bootstrap host and port resolve to a running name server. Root exception is org.omg.CORBA.COMM_FAILURE: WRITE_ERROR_SEND_1 minor code: 49421050 completed: No
| Explanation | This exception occurs when you run the launchClient command to a host server that does not have the Application Server started. You also receive this exception when you specify an invalid host server name. This situation might occur if you do not specify a host server name when you run the launchClient tool. The default behavior is for the launchClient tool to run to the local host, because WebSphere Application Server does not know the name of your host server. This default behavior only works when you are running the client on the same machine with WebSphere Application Server is installed. |
| Possible causes |
|
| Recommended response | If you are not running to the correct host server, run the launchClient command again and specify the name of your host server with the -CCBootstrapHost parameter. Otherwise, start the Application Server on the host server and run the launchClient command again. |
Error: javax.naming.NameNotFoundException: Name comp/env/ejb not found in context "java:"
| Explanation | This exception is thrown when the Java code cannot locate the specified name in the local JNDI name space. |
| Possible causes |
|
| Recommended response | Open the EAR file with the Application Server Toolkit, and check the bindings for the failing name. Ensure this information is correct. If you are using Resource References, open the EAR file with the Application Client Resource Configuration Tool , and verify that the Resource Reference has client configuration information and the name of the Resource Reference exactly matches the JNDI name of the client configuration. If the values are correct, you might have a class loader error. |
Error: java.lang.ClassCastException: Unable to load class: org.omg.stub.WebSphereSamples.HelloEJB._HelloHome_Stub at com.ibm.rmi.javax.rmi.PortableRemoteObject.narrow(portableRemoteObject.java:269)
| Explanation | This exception occurs when the application program attempts to narrow to the EJB home class and the class loaders cannot find the EJB client side bindings. |
| Possible causes |
|
| Recommended response | Look at the EJB .jar file located in the .ear file and verify the class contains the Enterprise Java Beans (EJB) client side bindings. These are class files with file names that end in _Stub and _Tie. If the binding classes are in the EJB .jar file, then you might have a class loader error. |
Error: WSCL0210E: The
Enterprise archive file [EAR file name] could not be found. com.ibm.websphere.client.applicationclient.ClientContainerException:
com.ibm.etools.archive.exception.OpenFailureException
| Explanation | This error occurs when the application client run time cannot read the Enterprise Archive (EAR) file. |
| Possible causes | The most likely cause of this error is that the system cannot find the EAR file cannot be found in the path specified on the launchClient command. |
| Recommended response | Verify that the path and file name specified on the launchclient command are correct. If you are running on the Windows operating system and the path and file name are correct, use a short version of the path and file name (8 character file name and 3 character extension). |
The launchClient command appears to hang and does not return to the command line when the client application has finished.
| Explanation | When running your application client using the launchClient command the WebSphere Application Server run time might need to display the security login dialog. To display this dialog, WebSphere Application Server run time creates an Abstract Window Toolkit (AWT) thread. When your application returns from its main method to the application client run time, the application client run time attempts to return to the
operating system and end the Java virtual machine (JVM) code. However, since there is an AWT thread, the JVM code will not end until System.exit is called. |
| Possible causes | The JVM code does not end because there is an AWT thread. Java code requires that System.exit() be called to end AWT threads. |
| Recommended response |
|
The applet client application client fails to launch an HTML browser in Internet Explorer
| Explanation | Applet client applications run only on Windows systems. When the applet client application runs, the application output data is displayed in a browser window. If you are using Internet Explorer with the Windows XP operating system for Service Pack 2 , then you might get errors when trying to display output data. |
| Possible causes | The Windows XP operating system for Service Pack 2 has a security feature that blocks pop-up browser windows from appearing. |
| Recommended response |
|
The WebSphere Trader Applet client does not function correctly with the Sun JVM plug-in version 1.4.1_02 on Linux
| Explanation | The WebSphere Application Server Trader Applet client is not working properly with the Sun Java™ Virtual Machine (JVM™) plug-in version 1.4.1_02 on Red Hat Enterprise Linux®, Red Flag Linux Adv Server and the SuSE Linux platform. |
| Possible causes | The WebSphere Application Server Trader Applet client is unsupported with the Sun JVM plug-in version 1.4.1_02 on Red Hat Enterprise Linux, Red Flag Linux Adv Server and the SuSE Linux platform. |
| Recommended response | When you run the WebSphere Application Server on any of the aforementioned platforms, use a browser from a different supported platform, such as Windows 2003, to run the Sample. |
"NoClassDefFoundError: Invalid Implementation Key" occurs when running an unmanaged client
| Explanation | When invoking an unmanaged client, a "NoClassDefFoundError: Invalid Implementation Key" exception might be observed for WebSphere Application Server classes. See the following example:Exception in thread "main" java.lang.NoClassDefFoundError: Invalid Implementation Key, com.ibm.ws.util.PlatformHelper at com.ibm.ws.util.ImplFactory.loadClassFromKey(ImplFactory.java:230) at com.ibm.ws.util.ImplFactory.loadImplFromKey(ImplFactory.java:179) at com.ibm.ws.util.ImplFactory.loadImplFromKey(ImplFactory.java:185) at com.ibm.ws.util.PlatformHelperFactory.getPlatformHelper(PlatformHelperFactory.java:51) ... |
| Possible causes | The likely cause of this problem is the removal of class path entries from the manifest of the WebSphere Application Server JAR files. This change of behavior compared to previous versions is intentional. It is not advisable to build a dependency on an implementation detail of WebSphere Application Server. |
| Recommended response | The preferred solution is to use the Java system properties to add the WebSphere library directory to the JDK extension classloader class path; that is:-Djava.ext.dirs=$JAVA_HOME/jre/lib/ext;$WAS_EXT_DIRS
where $WAS_EXT_DIRSis defined in setupCmdLine.bat or setupCmdLine.sh, or should at least contain $WAS_HOME/lib. See the following topic, for more information: Developing Thin application client code
on a server machine. If you require your own customized classloader to load the WebSphere Application Server library JAR files, a less preferable approach is available. This less preferable method requires the thread context classloader to be set to the customized classloader immediately after the custom classloader is created:Thread.currentThread().setContextClassLoader(...);This approach is less desirable, since be cautious about using your own customized classloader in the unmanaged client environment because of the potential hazards stemming from class dependency and delegation mode of hierarchy. An example of a common problem that results from this potential hazard is the classNotFoundException. |
Installing the Developer Kit feature downgrades the JRE files from Version 6.0.1 or Version 6.0.2 to Version 6.0
| Explanation | If you select the Developer Kit feature on the Application Client Version 6.0.0 installer, all the files are installed under the <client_install_root>/java directory, instead of leaving the Java Runtime Environment (JRE) files intact. The JRE files are unexpectedly downgraded to the Version 6.0.0 level. |
| Possible causes | Selecting the Developer Kit feature on the Application Client 6.0.0 installer will actually install all files under the <client_install_root>/java directory rather than leave the JRE files intact. Therefore, the JRE files are unexpected downgraded to the 6.0.0 level in the above installation scenario. |
| Recommended response | Complete the following installation steps to prevent unexpected downgrading of the JRE files. |
For current information available from IBM Support on known problems and their resolution, see the IBM customer support page.
IBM Support has documents that can save you time gathering information needed to resolve this problem. Before opening a PMR, see the IBM customer support page.