Sun Java System Application Server Enterprise Edition 8.1 2005Q2 Troubleshooting Guide

- Previous: How Do I Maintain a Session in JAX-RPC?
- Next: Are RMI-IIOP Stubs Needed to Access Remote EJBs?

# How Do I Access the Naming Service From a Standalone Java Client?

## To access the naming service from an application client

##### Steps

1. Include `appserv-rt.jar` in the `CLASSPATH` when starting the client Java VM.

   The JNDI bootstrapping machinery looks for a file called `jndi.properties,` which is located in `appserv-rt.jar`. This file contains all the bootstrapping properties for the Application Server’s naming service. It is better to have these properties read from `appserv-rt.jar` than to hard-code them in either the client startup script or in the application code.

2. When accessing remote EJBs from a standalone client, it is not necessary to retrieve the client JAR from the deployment or to put it in the client JVM’s `CLASSPATH`, because static RMI-IIOP stubs are not needed when using the Application Server naming service. This removes a step that was required in previous releases. (See Are RMI-IIOP Stubs Needed to Access Remote EJBs? for more details).

3. Code the client to use the default constructor `InitialContext` that does not require an argument. For example:

       InitialContext ic = new InitialContext();

   It is a common misconception that the client should be coded to explicitly reference the `CosNaming` service. `CosNaming` is only used for some kinds of Application Server objects, so doing this will not provide access to many of the kinds of resources you might need in the client such as JMS queues, connection factories, and so on. Furthermore, explicit use of `CosNaming` bypasses the Application Server’s naming service code. This often means that the client cannot take advantage of desirable value-added behavior built in to the Application Server’s naming service.

4. Use the global JNDI name of the target resource when doing the lookup. `java:comp/env` cannot be used from standalone Java clients, because by definition such clients run outside of a J2EE container. The only client component in which `java:comp/env` can be used is in a J2EE Application Client.

5. If the client is running on a different host machine than the server instance, set the following system property when starting the Java VM:

       -Dorg.omg.CORBA.ORBInitialHost=hostname_of_target_server

   This value defaults to `localhost` so it is only needed if the client and server instance are not colocated. For example:

       java -Dorg.omg.CORBA.ORBInitialHost=server1 ... com.foo.MyMainClass

6. By default, the client attempts to contact port `3700` to access the naming service in the server. Since `3700` is the default naming service port used by the Application Server, there is no additional port configuration needed in the client. In some cases, due to port conflicts, the server instance uses a different naming service port. The naming service port used by the server instance is listed in the `<iiop-listener id="orb-listener-1" port="3700"\>` element in `domain.xml`.

   To change the naming service port used by the client, set the following system property when starting the client Java VM:

       -Dorg.omg.CORBA.ORBInitialPort=naming_port_of_target_server

- Previous: How Do I Maintain a Session in JAX-RPC?
- Next: Are RMI-IIOP Stubs Needed to Access Remote EJBs?

- © 2010, Oracle Corporation and/or its affiliates