Cannot look up an object hosted by WAS from a servlet, JSP file, or other client

 

+

Search Tips   |   Advanced Search

 

To resolve problems encountered when a servlet, JSP file, standalone application or other client attempts to access an enterprise bean, ConnectionPool, or other named object hosted by WAS, first verify that the target server can be accessed from the client:

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

If you encounter this exception in trying to access an enterprise bean, data source, messaging resource, or other resource:

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

  • If you 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 may get this error if the object is being hosted on a different server.

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

To correct this problem, use the fully-qualified JNDIname:

  • If the object is in a single server: cell/nodes/nodeName/servers/serverName/jndiName. Objects are not supported in this release.

  • If the object is on a server cluster: cell/clusters/clusterName/jndiName.

 

CannotInstantiateObjectException from JNDI lookup operation

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

  • A serialized Java object is being looked up, but the necessary classes required to deserialize it are not in the runtime environment.

  • A Reference object is being looked up, and the associated factory used to process it as part of the lookup processing is failing.

To determine the precise cause of the problem:

  • Look in the JVM logs of the server hosting the target resource. Look for exceptions immediately preceding the CannotInstantiateObjectException. If it is a java.lang.NoClassDefFoundError or java.lang.ClassNotFoundException, make sure the class referenced in the error message can be located by the class loader.

  • Print out the stack trace for the root cause and look for the factory class. It will be called by javax.naming.NamingManager.getObjectInstance(). The reason for the failure will depend on the factory implementation, and may require you to contact the developer of the factory class.

 

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.

  • If no problems are being experienced, ignore this message. Also ignore the message if the problem you are experiencing does not appear to be related to the exception being reported and if there are no other adjacent error messages in the log.

  • If a problem is being experienced, look in the log for underlying error messages.

  • The information provided in message NMSV0610I can provide valuable debug data for other adjacent error messages posted in response to the Naming exception that occurred.

 

OperationNotSupportedException from JNDI Context operation

This error has two possible causes:

  • An update operation, such as a bind, is being performed with a name that starts with "java:comp/env". This context and its subcontexts are read-only contexts.

  • A Context bind or rebind operation of a non-CORBA object is being performed on a remote name space that does not belong to WAS. Only CORBA objects can be bound to these CosNaming name spaces.

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 that is 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 you 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 that 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 that 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 J2EE 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. The ServiceUnavailableException, like all NamingException objects, can be queried for a root cause. Check the root cause for more information. It is possible that some of the problems described for CommunicationExceptions may 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:

  • The host name or port in the provider URL is incorrect.

  • The host name cannot be resolved into an IP address by the domain name server, or the IP address does not match the IP address which the server is actually running under.

  • A firewall on the client or server is preventing the port specified in the provider URL from being used.

To correct this problem:

  • Make sure the provider URL and the network configurations on the client and server machines are correct.

  • Make sure the host name can be resolved into an IP address which can be reached by the client machine. We can do this using the ping command.

  • If you are running a firewall, make sure that use of the port specified in the provider URL will be allowed.

 

Related Tasks

Troubleshoot by task
Troubleshoot by component

 


 

 

IBM is a trademark of the IBM Corporation in the United States, other countries, or both.