Naming Conventions
Each naming service has its own mechanism for supplying a name. Perhaps the most
familiar naming convention is that of DNS, where every machine connected to the
Internet has a unique name and address. Most readers should recognize the following as
a host name used by DNS:
www.samspublishing.com
In contrast, LDAP names are based on the X.500 standard and use distinguished names
that look like the following fictitious example:
cn=Martin Bond, ou=Authors, o=SAMS, c=us
This format will also be familiar to users of Microsoft’s Active Directory service, whose
naming system is also based on X.500 but uses a forward slash to separate the various
name components:
cn=Martin Bond/ou=Authors/o=SAMS/c=us
These last two naming conventions have similarities in that they are both hierarchically
structured with the most specific name occurring first and the most general name (or
context) occurring last.
JNDI provides classes that support creating and manipulating structured names; but most
programmers will use simple strings that JNDI passes on to the underlying service with
minimal interpretation.
Some JNDI Service Providers may use names that are case sensitive, and some service
providers may not, it all depends on the underlying technology and environment. To
maintain portability of your applications, it is always best to avoid names that differ only
by letter case and also ensure that names are always spelled in a consistent manner.
Using JNDI
JNDI is a standard component of JDK 1.3 and is, therefore, also part of J2EE 1.3. JNDI
is also included in J2EE 1.2 and is available as a standard Java extension for JDK 1.2
and earlier.
While developing code, the program’s CLASSPATH must include the location of the JNDI
class libraries. As long as the JAVA_HOME environment variable has been set up, the JNDI
classes will be available to the Java compiler.
Running a JNDI-aware program requires a JNDI service to be running and the classes for
that service to be available to the program. Typically, this requires the CLASSPATH to
include one or more JAR files provided by the JNDI provider or a J2EE server vendor.
For implementation-specific details, see the vendor’s documentation.
By default, running a J2EE server starts a naming service on the same machine. If the
default behavior isn’t required, you must change the J2EE server configuration to use an
existing JNDI server.
Using Sun Microsystems’ J2EE Reference
Implementation
Using JNDI with Sun Microsystems’ J2EE Reference Implementation (RI) is straightforward.
Ensure that
• The J2EE_HOME variable exists
• The CLASSPATH variable includes the j2ee.jar file from the lib directory of the
J2EE home directory
Examples of how to do this both for Windows and for Unix are shown in this section.
J2EE RI for Windows
Under systems running Microsoft Windows NT or 2000, you can set the class path interactively
with the following:
Set CLASSPATH=%J2EE_HOME%\lib\j2ee.jar;%CLASSPATH%
Typically, it is better to set the class path as a system-wide environment variable (via the
My Computer properties dialog). A suitable value is as follows:
.;%J2EE_HOME%\lib\j2ee.jar
The class path can also include additional JAR files and directories for other Java components.
It is important to define the current directory (.) in the class path; otherwise, the Java
compiler and runtime systems will not find the classes for the program being developed.
J2EE RI for Linux and Unix
Under Linux and Unix, set the class path with the following:
CLASSPATH=$J2EE_HOME/lib/j2ee.jar:$CLASSPATH
Starting the JNDI Server
Startup the J2EE RI server, as Day 2, “The J2EE Platform and Roles,” described, and the
JNDI server will start at the same time. You start the J2EE server by entering the following
command from a command-line window:
j2ee –verbose
The J2EE server will run in that window until you close the window down or enter the
following shutdown command from another command-line window:
j2ee -stop
Obtaining an Initial Context
The first step in using the JNDI name service is to get a context in which to add or find
names. The context that represents the entire namespace is called the Initial Context and
is represented by a class called javax.naming.InitialContext and is a sub-class of the
javax.naming.Context class.
A Context object represents a context that you can use to look up objects or add new
objects to the namespace. You can also interrogate the context to get a list of objects
bound to that context.
The javax.naming package contains all the simple JNDI classes. Sub-packages within
the javax.naming package provide additional JNDI functionality, such as directorybased
features like attributes.
The following code creates an initial context using the default JNDI service information:
Context ctx = new InitialContext();
If something goes wrong when creating the initial context, a NamingException is thrown.
