Troubleshooting guide for the J2EE application client

This section provides debugging tips for resolving several 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.

Specify this command-line arguments for the launchClient script to generate a trace and to redirect the trace output to a file:

launchClient -CCtrace=true -CCtracefile=appclient.trc

In the example above, the resulting trace output is written to a file called appclient.trc in the current working directory.

Here are some possible errors:

Error: java.lang.NoClassDefFoundError

Explanation: This exception is thrown when Java cannot load the specified class.

Possible causes:

User response:

First check to determine if the specified class exists in a jar file within your ear file. If it does, make sure the package for the class is correct. For example, if you get the exception: 

java.lang.NoClassDefFoundError: WebSphereSamples.HelloEJB.HelloHome

ensure the class HelloHome exists in one of the jar files in your ear file. If it exists, ensure the package for the class is WebSphereSamples.HelloEJB.

If both the class and package are correct, then it is most likely a classpath issue. If this is the case, you do not have the failing jar file of the class specified in the client jar file's manifest. To verify this, open your Enterprise Archive (EAR) file with the Application Assembly Tool and click on the Application Client. Add the names of the other jar files in the ear file to the Classpath field. This exception is generally caused by a missing EJB module name from the Classpath field.

Note:If you have multiple jars 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 being loaded outside of the ear file. This is a very difficult situation to debug because the offending class is not the one specified in the exception. Instead, another class is loaded outside of the EAR file before the one specified in the exception. To correct this, review the classpaths specified with the -CCclasspath option and the classpaths 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 outside of the EAR file instead of the version contained in the EAR file. You do this by removing entries from the classpaths or by including the .jar files and classes in the EAR file instead of referencing them from outside of the EAR file.

If you are using the -CCclasspath parameter or resource classpaths in the Application Client Resource Configuration Tool, and you have configured multiple jars or classes, verify they are separated with the correct character for your operating system. Unlike the classpath field in the Application Assembly Tool, these classpath fields use platform-specific separator characters, usually a colon (on iSeries and UNIX platforms) or a semi-colon (on Windows 32-bit platforms).

Note: The system classpath is not used by the Application Client runtime if you use the launchClient script. In this case, the system classpath would not cause this problem. However, if you load the launchClient class directly, you do have to search through the system classpath 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 server. Your program looks up the name in the local client Java Naming and Directory Interface (JNDI) name space but receives a NameNotFoundException exception because the object is not located on the server. Looking up an enterprise bean that is not installed on the server is a typical example. 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 server-side resource.

Possible causes:

User response: If you are accessing the wrong server, run the launchClient script again with the -CCBootstrapHost and optionally the -CCBootstrapPort parameters specifying the correct server name and port number. If you are accessing the correct server and port number, use the dumpName Space utility to see a listing of the host-server's JNDI name space. For more information on the dumpName Space utility, see The dumpNameSpace script. If you do not see the failing object's name, either the resource is not installed on the 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 server. Use the Application Assembly Tool to compare the JNDI bindings of the client-side object's name to the JNDI bindings of the object in the server application. The bindings must match.

Error: javax.naming.ServiceUnavailableException: Caught exception when resolving initial reference=NameService. Root exception is org.omg.CORBA.INTERNAL: JORB00105: In Profile.getIPAddress(), InetAddress.getByName( invalidhostname ) threw an UnknownHostException minor code: 0 completed: No

Explanation: This exception occurs when you specify an invalid host server name or port number.

Possible causes:

User response: Run the launchClient script again and specify the correct name of your host server with -CCBootstrapHost and, optionally, -CCBootstrapPort.

Error:

javax.naming.CommunicationException: Caught CORBA.COMM_FAILURE when resolving initial reference=WsnNameService. Root exception is org.omg.CORBA.COMM_FAILURE: minor code: 3 completed: No

Explanation:This exception occurs when you run the launchClient script to a server that does not have the Application Server started. You also receive this exception when you specify an invalid server name or invalid port number. This might happen if you do not specify a server name when you run the launchClient script. The default behavior is for the launchClient script to run to localhost, because WebSphere Application Server does not know the name of your server.

Possible causes:

User Response: If you are not running to the correct server, run the launchClient script again and specify the server name with -CCBootstrapHost. Also, ensure that you have specified the -CCBootstrapPort parameter if neccessary.

Otherwise, start the Application Server on the server and run the launchClient script again.

Error: javax.naming.NameNotFoundException: Name comp/env/ejb not found in context "java:"

Explanation: This exception is thrown when Java cannot locate the specified name in the local JNDI name space.

Possible causes:

Explanation: Open the ear file with the Application Assembly Tool and check the bindings for the failing name. Ensure this information is correct. If it is correct, you could have a class loader problem.

Error: java.rmi.RemoteException: CORBA UNKNOWN 0 Maybe Nested exception is: org.omg.CORBA.UNKNOWN: minor code: 0 completed: Maybe

Explanation:This exception occurs when your server-side application component has a problem. For example, this exception displays when your J2EE Application client invokes an EJB method that has thrown an exception.

Possible causes:

User Response: Check the stdout.log and stderr.log files for your application server. For the default application server, these files are Default_Server_stdout.log and Default_Server_stderr.log and are located in the /QIBM/UserData/WebAS5/default/logs/ directory on your iSeries server. The log files should contain messages describing the cause of the 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's home class and the classloaders cannot find the EJB's client side bindings.

Possible causes:

User Response: Look at the EJB .jar file located in the .ear and verify the class contains the EJB client side bindings. These are class files whose names end in _Stub and _Tie. If these files are not present, then use the Application Assembly Tool to generate the binding classes. If the binding classes are in the EJB .jar file, then you might have a classloader issue.