Troubleshooting guide for the J2EE application client

This topic 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 these 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.

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 this exception:

java.lang.NoClassDefFoundError: WebSphereSamples.HelloEJB.HelloHome

ensure that 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 EAR file with the Application Assembly Tooland 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 an EJB module name missing 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 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, AIX, and Solaris 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 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. (See Run the J2EE application client for more information.)

If you are accessing the correct server and port number, use the WebSphere namespace dump utility to see a listing of the host server's JNDI name space. (See Namespace dump utility for more information.)

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 Toolto 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. See Run the J2EE application client for more information.

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 WAS 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. See Run the J2EE application client for more information about these two parameters.

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 Tooland 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 enterprise bean method that has thrown an exception.

Possible causes:

User Response: Check the SystemOut.log and SystemErr.log files for your application server. By default, they are located in the /QIBM/UserData/WebAS5/Base/instance/logs/server directory, where instance is the name of the instance and server is the name of the 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 enterprise bean's home class and the classloaders cannot find the enterprise bean's client side bindings.

Possible causes:

User Response: Look at the enterprise bean JAR file that is located in the EAR file and verify the class contains the enterprise bean 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 Toolto generate the binding classes. If the binding classes are in the enterprise bean JAR file, then you may have a classloader issue.

Error: WSCL0206E: File [EAR file name] is not a valid Enterprise Archive file. WSCL0100E: Exception received: com.ibm.etools.archive.exception.OpenFailureException

Explanation: This error occurs when the J2EE application client runtime cannot read the enterprise archive (EAR) file.

Possible cause: The most likely cause of this error is the EAR file cannot be found in the path specified on the launchClient command.

User Response: Verify that the path and filename specified on the launchclient command are correct. If you are running launchClient on Windows 32-bit workstation 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).