Java Reference
In-Depth Information
container JNDI registry will also store JDBC data sources, JMS queues, JMS connection
factories, JPA entity managers, JPA entity manager factories, JavaMail sessions, and so on.
Whenever a client (such as an EJB) needs to use a managed resource, it can get hold of
JNDI and look up the resource by its unique name.
Figure 5.3
shows how a typical JNDI
tree for a Java EE application server might look.
Figure 5.3. An example JNDI tree for an application server. All global resources, such as JDBC and JMS, are
bound to the root context of the JNDI tree. Each application has its own application context and EJBs, and other
resources in the application are bound under the application context.
As you can see from
figure 5.3
, resources are stored in a JNDI tree in a hierarchical manner.
This means that JNDI resource names look very much like your computer's file system
with folders and filenames. Resources also sometimes start with a protocol specification
such as
java:
, much like using
C:\
for your computer's main drive and
S:\
for a
mapped network drive. After you get a handle to a resource from a JNDI context, you can
use it as though it were a local resource.
Initializing a JNDI context
To use a resource stored in the JNDI context, a client has to initialize the context and look
up the resource. Despite the robustness of the JNDI mechanism itself, the code to do so is
pretty simple. It's similar to the configuration for a JDBC driver to connect to a database.
First and foremost, to connect to any naming or directory service, you need to obtain the
JNDI libraries provided by that service. This is no different than getting the right JDBC
driver to connect to your database. If you want to connect to LDAP, DNS, or your com-
puter's file system, you need the LDAP, DSN, and file system service providers, respect-
ively.
