WAS v8.5 > Reference > Troubleshooting tips

Application access problems

To resolve problems encountered when a servlet, JSP file, stand-alone application or other client attempts to access an enterprise bean, ConnectionPool, or other named object hosted by WebSphere Application Server, first verify the target server can be accessed from the client.

Follow these steps:

Continue only if there is no problem with connectivity and the target resource appears to be running.

What kind of error are you seeing?

If we do not see a problem that resembles yours, or if the information provided does not solve your problem, contact IBM support for further assistance.


NameNotFoundException from JNDI lookup operation

There are three causes for a NameNotFoundException:

Incorrect lookup name

If we encounter a NameNotFoundException when trying to access an enterprise bean, data source, messaging resource, or other resource:

  1. Determine the cause of the NameNotFoundException.

    Browse the properties of the target object in the dmgr console, and verify the JNDI name it specifies matches the JNDI name the client is using.

    If we are looking up an object that resides on a server different from the one from which the initial context was obtained, use the fully qualified name.

    • If access is from another server object such as a servlet accessing an enterprise bean and you are using the default context, not specifying the fully qualified JNDI name, you might get a NameNotFoundException if the object is hosted on a different server.

    • If access is from a stand-alone client, it might be the object you are attempting access is on a server different from the server from which you obtained the initial context.

  2. Use the fully-qualified JNDI name to correct the problem.

Object being looked up is not bound

To correct a NameNotFoundException where the object being looked up is not bound:

  1. If the object being looked up is an application object such as an enterprise bean, ensure the application is running.

  2. Run the dumpNameSpace tool to view the contents of the name space to verify the object being looked up is bound to the name space with the expected name.

Two servers with the same name running on the same host are being used to interoperate

If an application running on a server in node1 uses a remote object reference to an object that resides on a similarly named server in node2 and both nodes are installed on the same host, several different failures might occur:

  • JNDI lookups fail with a NameNotFoundException.
  • Object references obtained other than through JNDI lookups fail, most likely with an org.omg.CORBA.OBJECT_NOT_EXIST exception.
  • A remote object reference resolves incorrectly to an object in the local process because the object also exists in the local process. That is, a reference to a remote object on the server process in node2 resolves incorrectly to the same kind of object in the local process, which is the server process in node1.

Object references between servers in different nodes and on different hosts do not result in an exception even if the server names are not unique.

To fix the failures, set a Java virtual machine (JVM) custom property for the ORB, com.ibm.websphere.orb.uniqueServerName, to true for either or both servers:

  1. In the dmgr console, click Servers > Server Types > WebSphere application servers > server_name > Java and Process Management > Process definition > Java virtual machine > Custom properties > New.

  2. On the Custom Properties settings page, define the custom property:

    1. For Name, specify com.ibm.websphere.orb.uniqueServerName.

    2. For Value, specify true.

  3. Click OK.

  4. Click Save on the console task bar.

  5. Restart the application server.


CannotInstantiateObjectException from JNDI lookup operation

If we encounter this exception in trying to access an enterprise bean, data source, messaging resource, or other resource, possible causes include:

To determine the precise cause of the problem:


Message NMSV0610I appears in the server's log file, indicating that some Naming exception has occurred

This error is informational only and is provided in case the exception is related to an actual problem. Most of the time, it is not. If it is, the log file should contain adjacent entries to provide context.


OperationNotSupportedException from JNDI Context operation

This error has two possible causes:

To determine which of these errors is causing the problem, check the full exception message.


WSVR0046E: Failed to bind, ejb/jndiName: ejb/jndiName. Original exception : org.omg.CosNaming.NamingContextPackage.AlreadyBound

This error occurs two enterprise bean server applications were installed on the same server such that a binding name conflict occurred. That is, a jndiName value is the same in the two applications' deployment descriptors. The error will surface during server startup when the second application using that jndiName value is started.

To verify that this is the problem, examine the deployment descriptors for all enterprise bean server applications running in the server in search for a jndiName specified in more than one enterprise bean application.

To correct the problem, change any duplicate jndiName values to ensure that each enterprise bean in the server process is bound with a different name.


ConfigurationException from "new InitialContext" operation or from a JNDI Context operation with a URL name

If we are attempting to obtain an initial JNDI context, a configuration exception can occur because an invalid JNDI property value was passed to the InitialContext constructor. This includes JNDI properties set in the System properties or in some jndi.properties file visible to the class loader in effect. A malformed provider URL is the most likely property to be incorrect. If the JNDI client is being run as a thin client such the CLASSPATH is set to include all of the individual jar files required, make sure the .jar file containing the properties file com/ibm/websphere/naming/jndiprovider.properties is in the CLASSPATH.

If the exception is occurring from a JNDI Context call with a name in the form of a URL, the current JNDI configuration may not be set up properly so the required factory class name cannot be determined, or the factory may not be visible to the class loader currently in effect. If the name is a Java: URL, the JNDI client must be running in a Java EE client or server environment. That is, the client must be running in a container.

Check the exception message to verify the cause.

If the exception is being thrown from the InitialContext constructor, correct the property setting or the CLASSPATH.

If the exception is being thrown from a JNDI Context method, make sure the property java.naming.factory.url.pkgs includes the package name for the factory required for the URL scheme in the name. URL names with the Java scheme can only be used while running in a container.


ServiceUnavailableException from "new InitialContext" operation

This exception indicates that some unexpected problem occurred while attempting to contact the name server to obtain an initial context. We can query the ServiceUnavailableException for a root cause. Check the root cause for more information. Some of the problems described for CommunicationExceptions might also result in a ServiceUnavailableException.

Since this exception is triggered by an unexpected error, there is no probable cause to confirm. If the root cause exception does not indicate what the probable cause is, investigate the possible causes listed for CommunicationExceptions.


CommunicationException thrown from a "new InitialContext" operation

The name server identified by the provider URL cannot be contacted to obtain the initial JNDI context. There are many possible causes for this problem, including:

To correct this problem:


Related concepts:

Troubleshooting help from IBM
Class loaders


Related


Use naming
Troubleshooting namespace problems
View JVM logs


Reference:

Application startup problems


+

Search Tips   |   Advanced Search