Accessing the Naming Context

The Application Server provides a naming environment, or context, which is compliant with standard Java EE requirements.
A Context object provides the methods for binding
names to objects, unbinding names from objects, renaming objects,
and listing the bindings. The InitialContext is
the handle to the Java EE naming service that application components
and clients use for lookups.

The JNDI API also provides subcontext functionality. Much like
a directory in a file system, a subcontext is a context within a context.
This hierarchical structure permits better organization of information.
For naming services that support subcontexts, the Context class
also provides methods for creating and destroying subcontexts.

Each resource within a server instance must have a unique
name. However, two resources in different server instances or different
domains can have the same name.

Global JNDI Names

Global JNDI names are assigned according to the following precedence
rules:

A global JNDI name assigned in the sun-ejb-jar.xml, sun-web.xml, or sun-application-client.xml deployment descriptor file has the highest precedence.
See Mapping References.

A global JNDI name assigned in a mapped-name element
in the ejb-jar.xml, web.xml,
or application-client.xml deployment descriptor
file has the second highest precedence. The following elements have mapped-name subelements: resource-ref, resource-env-ref, ejb-ref, message-destination, message-destination-ref, session, message-driven, and entity.

A global JNDI name assigned in a mappedName attribute
of an annotation has the third highest precedence. The following annotations
have mappedName attributes: @javax.annotation.Resource, @javax.ejb.EJB, @javax.ejb.Stateless, @javax.ejb.Stateful, and @javax.ejb.MessageDriven.

A default global JNDI name is assigned in some cases
if no name is assigned in deployment descriptors or annotations.

For an EJB 2.x dependency or a session or entity bean
with a remote interface, the default is the fully qualified name of
the home interface.

For an EJB 3.0 dependency or a session bean with a
remote interface, the default is the fully qualified name of the
remote business interface.

If both EJB 2.x and EJB 3.0 remote interfaces are
specified, or if more than one 3.0 remote interface is specified,
there is no default, and the global JNDI name must be specified.

For all other component dependencies that must be
mapped to global JNDI names, the default is the name of the dependency
relative to java:comp/env. For example, in the @Resource(name="jdbc/Foo") DataSource ds; annotation, the
global JNDI name is jdbc/Foo.

Accessing EJB Components Using the CosNaming Naming Context

The preferred way of accessing the naming service, even in code
that runs outside of a Java EE container, is to use the no-argument InitialContext constructor. However, if EJB client code
explicitly instantiates an InitialContext that
points to the CosNaming naming service, it is necessary to set the java.naming.factory.initial property
to com.sun.jndi.cosnaming.CNCtxFactory in the client JVM when accessing EJB components. You can
set this property as a command-line argument, as follows:

The java.naming.factory.initial property
applies to only one instance; it is not cluster-aware.

Accessing EJB Components in a Remote Application
Server

The recommended approach for looking up an EJB component in
a remote Application Server from a client that is a servlet or EJB component
is to use the Interoperable Naming Service syntax. Host and port information
is prepended to any global JNDI names and is automatically resolved
during the lookup. The syntax for an interoperable global name is
as follows:

corbaname:iiop:host:port#a/b/name

This makes the programming model for accessing EJB components
in another Application Server exactly the same as accessing them in the
same server. The deployer can change the way the EJB components are
physically distributed without having to change the code.

For Java EE components, the code still performs a java:comp/env lookup on an EJB reference. The only difference is that
the deployer maps the ejb-reference element to
an interoperable name in an Application Server deployment descriptor file
instead of to a simple global JNDI name.

For example, suppose a servlet looks up an EJB reference using java:comp/env/ejb/Foo, and the target EJB component has
a global JNDI name of a/b/Foo.

Objects stored in the interoperable naming context and component-specific
(java:comp/env) naming contexts are transient.
On each server startup or application reloading, all relevant objects
are re-bound to the namespace.

Naming Environment for Lifecycle Modules

Lifecycle listener modules provide a means of running
short or long duration tasks based on Java technology within the application
server environment, such as instantiation of singletons or RMI servers.
These modules are automatically initiated at server startup and are
notified at various phases of the server life cycle. For details about
lifecycle modules, see Chapter 13, Developing Lifecycle Listeners.

The configured properties for a lifecycle module are passed
as properties during server initialization (the INIT_EVENT).
The initial JNDI naming context is not available until server initialization
is complete. A lifecycle module can get the InitialContext for
lookups using the method LifecycleEventContext.getInitialContext() during, and only during, the STARTUP_EVENT, READY_EVENT, or SHUTDOWN_EVENT server
life cycle events.