Lookup names support in deployment descriptors and thin clients
Server application objects, such as enterprise bean (EJB) homes, are bound relative to the server root context for the server in which the application is installed. Other objects, such as resources, can also be bound to a specific server root. The names used to look up these objects must be qualified so as to select the correct server root. This topic discusses what relative and qualified names are, when they can be used, and how we can construct them.
Beginning in Version 8.0, EJB homes are bound under the name, java:global/appName/moduleName/beanName. Names of that form are not topology-based and are fully-qualified already. Similarly, all application resources that are bound with java:global, java:app, or java:module names need no additional qualification when the java:global, java:app, or java:module lookup name is specified. Application resources include, for example, EJB references, resource references, and environment entries.
Relative names
All names are relative to a context. Therefore, a name that can be resolved from one context in the namespace cannot necessarily be resolved from another context in the namespace. This point is significant because the system binds objects with names relative to the server root context of the server in which the application is installed. Each server has its own server root context. The initial JNDI context is by default the server root context for the server identified by the provider URL used to obtain the initial context. (Typically, the URL consists of a host and port.) For applications running in a server process, the default initial JNDI context is the server root for that server. A relative name will resolve successfully when the initial context is obtained from the server which contains the target object, but it will not resolve successfully from an initial context obtained from another server.
If all clients of a server application run in the same server process as the application, all objects associated with that application are bound to the same initial context as the clients' initial context. In this case, only names relative to the server's server root context are required to access these server objects. Frequently, however, a server application has clients that run outside the application's server process. The initial context for these clients can be different from the server application's initial context, and lookups on the relative names for server objects may fail. These clients need to use the qualified name for the server objects. This point must be considered when setting up the jndiName values in a Java EE client application deployment descriptors and when constructing lookup names in thin clients. Qualified names resolve successfully from any initial context in the cell.
Qualified names
All names are relative to a context. Here, the term qualified name refers to names that can be resolved from any initial context in a cell. This action is accomplished by using names that navigate to the same context, the cell root. The rest of the qualified name is then relative to the cell root and uniquely identifies an object throughout the cell. All initial contexts in a server (that is, all naming contexts in a server registered with the ORB as an initial reference) contain a binding with the name cell, which links back to the cell root context. All qualified names begin with the string cell/ to navigate from the current initial context back to the cell root context.
A qualified name for an object is the same throughout the cell. The name can be topology-based, or some fixed name bound under the cell persistent root. Topology-based names, described in more detail later in this section, navigate through the system namespace to reach the target object. A fixed name bound under the cell persistent root has the same qualified name throughout the cell and is independent of the topology. Creating a fixed name under the cell persistent root for a server application object requires an extra step when the server application is installed, but this step eliminates impacts to clients when the application is moved to a different location in the cell topology. The process for creating a fixed name is also described later.
Generally, use qualified names for EJB jndiName values in a Java EE client application deployment descriptors and for EJB lookup names in thin clients. The only exception is when the initial context is obtained from the server in which the target object resides. For example, a session bean which is a client to an entity bean can use a relative name if the two beans run in the same server. If the session bean and entity beans run in different servers, the jndiName for the entity bean must be qualified in the session bean's deployment descriptors. The same requirement may be true for resources as well, depending on the scope of the resource.
- Topology-based names
The system namespace partition in a cell's namespace reflects the cell's topology. This structure can be navigated to reach any object bound into the cell's namespace. Topology-based qualified names include elements from the topology which reflect the object's location within the cell.
For a system-bound object, such as an EJB home, the form for a topology-based qualified name depends on whether the object is bound to a single server or cluster. Both forms are described as follows:
- Single server
- An object bound in a single server has a topology-based qualified name of the following form:
cell/nodes/nodeName/servers/serverName/relativeJndiName
where nodeName and serverName are the node name and server name for the server where the object is bound, and relativeJndiName is the unqualified name of the object; that is, the object's name relative to its server's server root context.
- Server cluster
- An object bound in a server cluster has a topology-based qualified name of the following form:
cell/clusters/clusterName/relativeJndiName
where clusterName is the name of the server cluster where the object is bound, and relativeJndiName is the unqualified name of the object; that is, the object's name relative to a cluster member's server root context.
- Fixed names
It is possible to create a fixed name for a server object so that the qualified name is independent of the cell topology. This quality is desirable when clients of the application run in other server processes or as pure clients. Fixed names have the advantage of not changing if the object is moved to another server. The jndiName values in deployment descriptors for a Java EE client application can reference the qualified fixed name for a server object regardless of the cell topology on which the client or server application is being installed.
Define a cell-wide fixed name for a server application object requires an extra step after the server application is installed. That is, a binding for the object must be created under the cell persistent root. A fixed name bound under the cell persistent root can be any name, but all names under the cell persistent root must be unique within the cell because the cell persistent root is global to the entire cell.
A qualified fixed name has the form:
cell/persistent/fixedName
where fixedName is an arbitrary fixed name.
The binding can be created programmatically (for example, using JNDI). However, it is probably more convenient to configure a cell-scoped binding for the server object.
We must keep the programmatic or configured binding up-to-date. Configured EJB bindings are based on the location of the enterprise bean within the cell topology, and moving the EJB application to another server, for example, requires the configured binding to be updated. Similar changes affect an EJB home reference programmatically bound so that the fixed name would need to be rebound with a current reference. However, for Java EE clients, the jndiName value for the object, and for thin clients, the lookup name for the object, remains the same. In other words, clients that access objects by fixed names are not affected by changes to the configuration of server applications they access.
Use lookup names in deployment descriptor bindings
Java EE applications can contain deployment descriptors, such as ejb-ref, resource-ref, and resource-env-ref, used to declare various types of references. These reference declarations define java:comp/env lookup names that are available to corresponding Java EE components. Each java:comp/env lookup name must be mapped to a lookup name in the global name space, relative to the server root context, which is the default initial JNDI context.
If a reference maps to an object that is bound under the server root context for the same server as the component that is executing the lookup, we can use a relative lookup name. If a reference maps to an object that is bound under the server root context of another server, you must qualify the lookup name. For example, you must qualify a lookup name if a servlet, running on one server, declares an ejb-ref for an EJB running on another server. Similarly, if the reference maps to an object that is bound into a persistent partition of the name space, or to an object that is bound through a cell-scoped or node-scoped configured name space binding, use a qualified name.
We can specify deployment descriptor reference binding values when you install the application, and edit them after the application is installed. If we need to change the JNDI lookup name a reference maps to, in the console, click Applications > Application Types > WebSphere enterprise applications > application_name. In the References section, there are links that correspond to the various reference types, such as EJB references and Resource environment entry references, that are declared by this application. Click on the link for the reference type that we need to change, and then specify a new value in the Target Resource JNDI Name field.
Related concepts
Naming Namespace logical view Configured name bindings
Related tasks
Develop applications that use JNDI Use naming Develop applications that use CosNaming (CORBA Naming interface)
Initial context support