Jonathan said:
I'm having some trouble understanding JNDI concepts. Specifically, I'm
not clear on how resource-ref's and resource-env-ref's work, what they
are used for, what the difference is between them, and so forth.
First, you need to understand how J2EE works relative to external
resources. Most J2EE applications utilize an external resource, for
example a database. Typically database interaction is done via a JDBC
driver. The preferred method for obtaining a database connection in a
J2EE environment is from a javax.sql.DataSource implementation provided
by the container.
So the container will provide your application with a
javax.sql.DataSource. The benefits of this are that your application
doesn't need to be concerned with the configuration details of the
javax.sql.DataSource. Also, the application server can provide services
like connection pooling or SQL tracing without affecting you
application. Finally, your application is shielded from the details
like the specific JDBC driver used and the database vendor. (Although
sometime sufficiently complicated applications need to know this data
anyways.)
So now that we know what we want from the application server and the
application, we need to understand how it is accomplished. At a high
level, it works this way. The container provides to each web
application and/or EJB a particular JNDI context that is theirs and
theirs alone. This is called the ENC context and is accessed via the
name java:comp/env. Best practices dictate that you access external
resources from this context. For example, you may decide that you will
access the javax.sql.DataSource from the JNDI under the name
java:comp/env/jdbc/MyAppDS. You can safely hardcode that value into
from Java code because it is really a logical value. In the
configuration file for the component (web.xml or ejb-jar.xml), you
declare what these names are and what you expect to find there. (These
are the entries you asked about.)
OK, so the application knows where in the ENC context it will access
external resources. Next the application server must be configured to
actually have the external resources. This is performed in an
application server specific manner. E.g., you might configure your
application server to contain an Oracle implementation of
javax.sql.DataSource under the JNDI name java:jdbc/OracleOnDB1DS.
The final step is to tell the application server how to map the logical
names in the ENC context for your component to the physical resources
configured in the application server. How this is done is application
server specific. Almost every application server provides the
capability for specifying this in an XML file that lives alongside the
web.xml or ejb-jar.xml file. For some application servers, this is the
only way. Other application servers provide a GUI of some sort for
deploying applications and you do that then. In the example we have
used, we map java:comp/env/jdbc/MyAppDS to java:jdbc/OracleOnDB1DS.
Note one other benefit of this scheme. You can deploy a second copy of
your component in the same application server or even in the same EAR
and use the configuration to have it point to different physical
resources. E.g., we could have a duplicate component where
java:comp/env/jdbc/MyAppDS is mapped to java:jdbc/MSSqlServerOnDB2DS.
HTH,
Ray
