+

Search Tips   |   Advanced Search

Application client troubleshooting tips

Debug common JEE application client problems using this troubleshooting guide. Review the trace entries for one of the Java EE 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. We might find it useful to rerun the launchClient command specifying the -CCverbose=true option. This option provides additional information when the Java EE application client run time is initializing.


Error: java.lang.NoClassDefFoundError

Explanation Possible causes Recommended response
This exception is thrown when Java code cannot load the specified class.

  • Invalid or non-existent class

  • Class path problem

  • Manifest problem

Check to determine if the specified class exists in a Java Archive (JAR) file within the 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.HelloHome

verify that the HelloHome class exists in one of the JAR files in the 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, we do not have the failing class JAR file specified in the client JAR file manifest. To verify this situation, perform the following steps:

  1. Open the EAR file with an assembly tool, and select the Application Client.

  2. Add the names of the other JAR files in the EAR file to the Classpath field.
This exception is generally caused by a missing Enterprise Java Beans (EJB) module name from the Classpath field.

If we have multiple JAR files to enter in the Classpath field, be sure to separate the JAR names with spaces.

If we still have the problem, we 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.

Alternatively, we can use the Client Container Resource Configuration Scripting tool.

Look for classes that also exist in the EAR file. We 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 tool, and we have configured multiple JAR files or classes, verify they are separated with the correct character for the operating system. Unlike the Classpath field, these class path fields use platform-specific separator characters.

The separator character is a colon.

The separator character is semi-colon.

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

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 Possible causes Recommended response
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 component that is not installed on the host server that you access. This exception might also occur if the JNDI name you configured in the Application Client module does not match the actual JNDI name of the resource on the host server.

  • Incorrect host server invoked

  • Resource is not defined

  • Resource is not installed

  • Application server is not started

  • Invalid JNDI configuration

If we are accessing the wrong host server, run the launchClient command again with the -CCBootstrapHost parameter specifying the correct host server name. If we are accessing the correct host server, use the product dumpnamespace tool to see a listing of the host server JNDI name space. If we 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 we determine the resource is already installed and started, the JNDI name in the client application does not match the global JNDI name on the host server. Use an assembly tool 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

Error: javax.naming.ServiceUnavailableException: A communication failure occurred while attempting to obtain an initial context using the provider url: "iiop://[invalidhostname]". Make sure 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 Possible causes Recommended response
This exception occurs when specified an invalid host server name.

  • Incorrect host server invoked

  • Invalid host server name

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


Error: javax.naming.CommunicationException

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 Possible causes Recommended response
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 specified an invalid host server name. This situation might occur if we 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 WAS does not know the name of the host server. This default behavior only works when we are running the client on the same machine with WebSphere Application Server is installed.

  • Incorrect host server invoked

  • Invalid host server name

  • Invalid reference to localhost

  • Application server is not started

  • Invalid bootstrap port

If we are not running to the correct host server, run the launchClient command again and specify the name of the host server with the -CCBootstrapHost parameter. Otherwise, start the Application Server on the host server and run the launchClient command again.


Error: javax.naming.CommunicationException

Error: javax.naming.CommunicationException: Could not get the users matching the pattern wasuser6 because of the following exception javax.naming.CommunicationException: simple bind failed: server_location. Root exception is javax.net.ssl.SSLHandshakeException: Remote host closed connection during handshake.

Explanation Possible causes Recommended response
This exception occurs when you enable administrative, application, and Java 2 security using the LDAP user registry. The deployment manager restarts successfully, but we cannot log into the administrative console. The error message appears in the SystemOut.log.

  • The SSL enabled option is checked on the Standalone LDAP registry configuration panel.

  • The LDAP port number or host name are wrong. The LDAP server certificate is wrong or expired on the LDAP server.

  • The certificate authority (CA) is not imported to WebSphere Application Server, or it is wrong.

  • The SSL configuration is wrong.

  • There is a network problem.

Clear the SSL enabled option and attempt the connection again. The SSL enabled option specifies whether to protect connections between the WAS plug-in and application server with SSL. The default is not to use SSL.


Error: javax.naming.NameNotFoundException

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

Explanation Possible causes Recommended response
This exception is thrown when the Java code cannot locate the specified name in the local JNDI name space.

  • 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 classes

  • A resource reference does not include any client configuration information

  • A client container on the deployment manager is trying to use enterprise extensions (not supported)

Open the EAR file with an assembly tool, and check the bindings for the failing name. Ensure this information is correct. If we 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, we might have a class loader error.


Error: java.lang.ClassCastException

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 Possible causes Recommended response
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.

  • The files, *_Stub.class and _Tie.class, are not in the EJB .jar file

  • Class loader could not find the classes

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 we might have a class loader error.


Error: WSCL0210EError: java.lang.NoClassDefFoundError

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 Possible causes Recommended response
This error occurs when the application client run time cannot read the EAR file. The most likely cause of this error is that the system cannot find the EAR file in the path specified on the launchClient command. Verify that the path and file name specified on the launchclient command are correct.

If we 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 Possible causes Recommended response
When running the application client using the launchClient command the WAS 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 the 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 JVM code. However, since there is an AWT thread, the JVM code will not end until System.exit is called. The JVM code does not end because there is an AWT thread. Java code requires that System.exit() be called to end AWT threads.

  • Modify the application to call System.exit(0) as the last statement.

  • Use the -CCexitVM=true parameter when you call the launchClient command.


The applet client application client fails to launch an HTML browser in Internet Explorer

Explanation Possible causes Recommended response
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 we 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. The Windows XP operating system for Service Pack 2 has a security feature that blocks pop-up browser windows from appearing.

  • Locate the information bar found under the URL Address bar in the Internet Explorer pop-up browser that has been blocked.

  • Click the Information Bar to display options that disable the operating system security feature.

  • Select Allow blocked content. We are prompted with a security window asking you to confirm the selection to allow blocked content.

  • Click Yes.

  • The applet client application runs successfully, and the browser information is displayed appropriately.

Before opening a problem report, see the Support page:


Related tasks

  • Running a Java EE client application with launchClient
  • Start the Application Client Resource Configuration Tool and opening an EAR file Reference topic