Using JNDI Outside J2EE

JNDI is a required technology for J2SE so you do not need to have a full blown J2EE server in order to use JNDI. In fact if you do any work with RMI-IIOP (CORBA) you will be using JNDI to bind and look up the RMI server objects. This is discussed in detail on Day 19. You may also find yourself using JNDI to access an LDAP service, or Microsoft's Active Directory service through its LDAP interface.

If you are working outside of the J2EE environment there are two obvious questions that need answering:

The supplementary question is then:

• What happens if I don't define the JNDI service correctly?

The following sections discuss the answers to these questions.

Defining the JNDI Service

The parameters that you usually need to define for a JNDI service are as follows:

• The Name Service provider classname

• The Name Service host name

• The Name Service port number

A particular server vendor's implementation may require additional parameters.

There are several ways of defining the JNDI service properties for a program, but you only need to use one of them. You can

• Add the properties to the JNDI properties file in the Java runtime home directory

• Provide an application resource file for the program

• Specify command-line parameters to be passed to an application

• Hard-code the parameters into the program

The last option is considered poor practice because it obviously restricts the program to working with one type of JNDI service provider on one specific host.

The first two options are the most suited to production environments. They both require that you distribute simple text configuration files with the program.

JNDI Properties Files

An application resource file called jndi.properties defines the JNDI service. The JNDI system automatically reads the application resource files from any location in the program's CLASSPATH and from lib/jndi.properties in the Java runtime home directory (this is the jre sub-directory of the Java JDK home directory).

The following example shows the jndi.properties file for working with the CORBA name service supplied with the J2SE (discussed on Day 19):

java.naming.factory.initial=com.sun.jndi.cosnaming.CNCtxFactory
java.naming.provider.url=iiop://localhost:1050

Each entry in the property file defines a name value pair. The InitialContext object uses these properties to determine the JNDI service provider.

The service provider usually supplies a sample jndi.properties file defining the properties that need to be configured with their server. Often the jndi.properties file is a component of the JAR files you include in your application's CLASSPATH.

Normally, any given JNDI service will require the following named properties:

java.naming.factory.initial

You set this property to the classname (including the package) of the Initial Context Factory for the JNDI Service Provider. This value effectively defines which JNDI Service Provider you will use. The classes for the service provider must be included in the CLASSPATH for your application.

java.naming.provider.url

This defines the URI of the machine running the JNDI service. Often this value omits the protocol prefix and simply defines the hostname and port number. This is the only property that the network administrator needs to customize.

More information on these and other JNDI properties can be found in the API documentation for the Context class and in the JNDI Tutorial from Sun Microsystems.

The simplest way to define the JNDI Service Provider is to configure every client's Java home directory to include the necessary JNDI properties. This approach suits an intranet where all machines are centrally managed.

Another approach is to include a suitable JNDI properties file with the client program and distribute everything as a JAR file (program class files and the jndi.properties file). This suits Web-based intranets or extranets, where applets are used or where you can distribute the client JAR file to users.

Application Properties

Using the -D option, you can supply the JNDI properties on the java command line of an application. This has the disadvantage of requiring long command lines that are hard to remember and easy to mistype. A way around this problem is for you to provide script files to run the application on the target platforms; typically, you might supply Apache Ant build scripts, batch files for Windows, or shell scripts for Linux and Solaris.

The following is an example of a command line that defines the CORBA Name Service factory classes and server:

Java -Djava.naming.factory.initial=com.sun.jndi.cosnaming.CNCtxFactory -Djava.naming
.provider.url=iiop://localhost:1050 MyClass

Providing a jndi.properties file in the application JAR file is a cleaner solution than providing command-line parameters. However, using command-line parameters makes the JNDI properties more apparent when customizing the application for a local site. It is easy to overlook a jndi.properties file in a JAR file.

Hard-Coded Properties

The least desirable way to specify the JNDI properties is via hard-coded values in the program. Hard coding the properties means including the JNDI class names and the server URI in the source code. This is undesirable because should the network architecture change, you must edit, recompile, and redistribute the program. Obviously, you will want to avoid this type of maintenance overhead if you can. The network architecture may change if the JNDI service moves to a different server or you install a new JNDI Service Provider.

The mechanism for defining the service in code is via a hash table of properties passed into the InitialContext constructor:

Hashtable env = new Hashtable();
env.put(Context.INITIAL_CONTEXT_FACTORY,
  "com.sun.jndi.cosnaming.CNCtxFactory");
env.put(Context. PROVIDER_URL,  " iiop://localhost:1050");
Context ctx = new InitialContext(env);

Notice how the code uses symbolic constants from the Context class rather than using strings representing the properties (such as "java.naming.factory.initial"). This approach makes the code more portable should the property names change in future versions of Java or JNDI.

Having made your decision about how to define the JNDI properties you may still make mistakes, such as not setting the CLASSPATH correctly. The next section takes a quick look at the symptoms of common mistakes made when using JNDI.

Initial Context Naming Exceptions

The exceptions most likely to occur when creating the JNDI InitialContext object are as follows:

javax.naming.CommunicationException: Can't find SerialContextProvider

This exception usually means the JNDI Server is not running, or possibly the JNDI properties for the server are incorrect.

javax.naming.NoInitialContextException: Need to specify class name in environment or
 system property, or as an applet parameter, or in an application resource file: java
.naming.factory.initial

This exception occurs when the InitialContext class does not have default properties for the JNDI Service Provider, and the JNDI server properties have not been configured explicitly.

javax.naming.NoInitialContextException: Cannot instantiate class: XXX
 [Root exception is java.lang.ClassNotFoundException: XXX]

This exception occurs when the class path defined for the JNDI program does not include the JNDI server classes.

javax.naming.ServiceUnavailableException: Connection refused: no further information [Root
 exception is java.net.ConnectException: Connection refused: no further information]

This exception occurs when the JNDI properties for the program fail to match the JNDI Service Provider currently in use.