Operating Systems: i5/OS
Personalize the table of contents and search results
Application access problems
To resolve problems encountered when a servlet, JavaServer Pages
file, standalone application or other client attempts to access an enterprise
bean, ConnectionPool, or other named object hosted by WebSphere Application Server,
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, 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 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 might get a NameNotFoundException if the object
is hosted on a different server.
- If access is from a standalone 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 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 Servers > Application Servers
> server_name > Java and Process Management > Process Definition
> Java Virtual Machine > Custom Properties > New.
- 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:
- Look at the relevant logs 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.
View
the JVM logs.
- 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 WebSphere Application Server.
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. 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.
Related tasks
Using naming
Troubleshooting name space problems
Reference topic