• JBossSupport
• JNDI

Overview

From the Sun JNDI Product Overview:

Naming and directory services play a vital role in intranets and the Internet by providing network-wide sharing of a variety of information about users, machines, networks, services, and applications.

JNDI is an API specified in Java technology that provides naming and directory functionality to applications written in the Java programming language. It is designed especially for the Java platform using Java's object model. Using JNDI, applications based on Java technology can store and retrieve named Java objects of any type. In addition, JNDI provides methods for performing standard directory operations, such as associating attributes with objects and searching for objects using their attributes.

JNDI is also defined independent of any specific naming or directory service implementation. It enables applications to access different, possibly multiple, naming and directory services using a common API. Different naming and directory service providers can be plugged in seamlessly behind this common API. This enables Java technology-based applications to take advantage of information in a variety of existing naming and directory services, such as LDAP, NDS, DNS, and NIS(YP), as well as enabling the applications to coexist with legacy software and systems.

Using JNDI as a tool, you can build new powerful and portable applications that not only take advantage of Java's object model but are also well-integrated with the environment in which they are deployed.

DataSource Naming

DataSource names should be based upon the database/schema name for a given connection. For example, if an application were to connect using a default schema named MYAPP, then the DataSource would be named MYAPP. In the event that a default schema/database is not supplied (typical in legacy applications), a short application based name should be used instead.

EJB Naming

EJB names should reflect the base class name of the reference being placed into JNDI. For EJB versions prior to 3.0 this would use the Home interface. EJB versions 3.0 and up use the @Local, @Remote, or application interface. For example, an EJB 2.1 Session Bean named CustomerService would have an ejb-name of CustomerServiceHome. Under EJB 3.0, that name should be changed to CustomerService.

Environment Naming Context (ENC)

A J2EE component locates its environment naming context using the JNDI interfaces. A component creates a javax.naming.InitialContext object and looks up the environment naming context under the name java:comp/env. A component's naming environment is stored directly in the environment naming context or in any of its direct or indirect subcontexts.

An object should be named within a subcontext of the naming environment according to the type of the object. The following subcontexts should be used when creating a new resource:

For example if a DataSource named MYAPP were to be placed into JNDI for management, it should have a subcontext of jdbc/. As such, the full ENC path to the resource would be java:comp/env/jdbc/MYAPP.

See Also

• Sun JNDI Product Page

• JBoss Naming Wiki Page