InfoCenter Home >
4: Developing applications >
4.7: Java Clients >
4.7.2: J2EE application client programming model >
4.7.2.3: Troubleshooting guide for the J2EE application client

4.7.2.3: Troubleshooting guide for the J2EE application client

This section provides some debugging tips for resolving common 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. See the Problem determination section for more information on starting traces and reading trace entries. Also see the WSCL Messages for a description of application client messages. These messages help identify problems and can provide recovery information.


Error:   java.lang.NoClassDefFoundError

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

Possible causes:  

  • Invalid or non-existent class
  • Classpath problem
  • Manifest problem

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 path 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 path for the class is WebSphereSamples.HelloEJB.

If both the class and path are correct, then it is a classpath issue. Most likely, you do not have the failing class's jar file specified in the client jar file's manifest. To check this, open your 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.

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 from the hard drive instead 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 from the hard drive 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 on the hard drive instead of 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 the hard drive.

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 UNIX platforms) or a semi-colon (on Windows).

Note:   The system classpath is not used by the Application Client runtime if you use the launchClient batch or shell files. 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.

Return


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

  • Incorrect host server invoked
  • Resource is not defined
  • Resource is not installed
  • Application server is not started
  • Invalid JNDI configuration

User 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 WebSphere dumpnamespace command line tool to see a listing of the host server's JNDI name space. If you do not see the failing object's 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 Assembly Tool to compare the JNDI bindings value of the failing object's name in the client application to the JNDI bindings value of the object in the host server application. They must match.

Return


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.

Possible causes:  

  • Incorrect host server invoked
  • Invalid host server name

User response:   Run the launchClient command again and specify the correct name of your host server with the -CCBootstrapHost parameter.

Return


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 launchClient 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 might happen if you do not specify a host server name when you run launchClient. The default behavior is for launchClient to run to localhost, 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 computer as where WebSphere Application Server is installed.

Possible causes:  

  • Incorrect host server invoked
  • Invalid host server name
  • Invalid reference to localhost
  • Application server is not started
  • Invalid bootstrap port

User 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.

Return


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:  

  • No binding information for the specified name
  • Binding information for the specified name is incorrect
  • Wrong class loader was used to load one of the program's classes
User Response:   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 issue.

Return



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.

Note:  The HelloHome_Stub reference in the Error description, is a sample

Possible causes:  

  • The files, *_Stub.class and _Tie.class, are not in the EJB .jar file
  • Classloader could not find the classes
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. For more information, see article Generating deployment code for modules. If the binding classes are in the EJB .jar file, then you might have a classloader issue.

Return



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 Application Client runtime cannot read the Enterprise Archive 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 on Windows NT 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). For additional information, read the cause and recovery documentation for message WSCL0206E in the 8.2 Messages section.

Return


Go to previous article: Developing a J2EE application client Go to next article: J2EE application client classloading overview

 

 
Go to previous article: Developing a J2EE application client Go to next article: J2EE application client classloading overview