To resolve problems encountered when a servlet, JavaServer
Pages file, stand-alone application or other client attempts to access
an enterprise bean, ConnectionPool, or other named object hosted by WebSphere® Application Server, you must first
verify that the target server can be accessed from the client.
Follow these steps:
- From a command prompt on the client's server, enter ping server_name and
verify connectivity.
- Use the administrative console to verify that the target resource's
application server and, if applicable, enterprise bean (EJB) module
or web module, is started.
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
There are three causes for a NameNotFoundException:
- Incorrect lookup name
- If you encounter a NameNotFoundException when trying to access
an enterprise bean, data source, messaging resource, or other resource:
- Determine the cause of the NameNotFoundException.
Browse the
properties of the target object in the administrative console, and
verify that the Java Naming and Directory Interface
(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, you must 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 that the object
you are attempting access is on a server different from the server
from which you obtained the initial context.
- Use the fully-qualified JNDI name to correct the problem.
If the object is in a single server, the fully-qualified
JNDI name is as follows:
cell/nodes/nodeName/servers/serverName/jndiName
Restriction: Objects are not supported in this release.
If the object is on a server cluster, the fully-qualified
JNDI name is as follows:
cell/clusters/clusterName/jndiName
- Object being looked up is not bound
- To correct a NameNotFoundException where the object being looked
up is not bound:
- If the object being looked up is an application object such as
an enterprise bean, ensure that the application is running.
- Run the dumpNameSpace tool to
view the contents of the name space to verify that 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 Object Request Broker (ORB), com.ibm.websphere.orb.uniqueServerName,
to
true for either or both servers:
- In the administrative console, click .
- On the Custom Properties settings page, define the custom property:
- For Name, specify com.ibm.websphere.orb.uniqueServerName.
- For Value, specify true.
- Click OK.
- Click Save on the console task bar.
- Restart the application server.
To prevent similar failures with the node
agent, you can set the node agent Java virtual machine custom property
ORB, com.ibm.websphere.orb.uniqueServerName, to true.
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:
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 the product.
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 Java Platform,
Enterprise Edition (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. You 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:
- 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. You 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.