188.8.131.52. Two-level name resolution
Many application servers support two-level name bindings for the linking of JNDI names
to actual assets. This capability offers flexibility and, in some cases, efficiency when
operating a number of components and applications in the same server.
Two-level name binding allows you to assign an independent name to an asset when
configuring it within the application server and then link this asset name to the name
specified in the component deployment descriptors. Suppose, for example, that a
deployment descriptor declares a requirement for a JavaMail Session to be deployed on
the server under the name java:comp/env/mail/AppSession. If the application server
supports two-level name bindings, we can configure a Session on the server under an
independent name, such as java:comp/mail/GenericSession, and link the asset name to
the name required by the component module. In effect, this linking ensures that the
runtime JNDI lookup at java:comp/env/mail/AppSession actually resolves to the
Session deployed under java:comp/mail/GenericSession. The mechanics of making this
linkage is application-dependent—it can be done in a server-specific configuration file, in
a web administration tool, or in something else entirely. Later in this chapter, we'll see a
concrete example of configuring an asset this way in JBoss.
Not only does this two-level binding feature allow you to manage your namespace more
flexibly, but it can also make it possible to share assets among components and applications
running in the same server. Following on to the Session example we just used, suppose
this Session were configured with fairly generic settings and that other components also
needed a Session configured similarly. We can reuse the same Session asset with other
components by simply linking the names that these other components declare for the asset
with the same Session that is deployed at java:comp/mail/GenericSession.