Re: JNDI and J2EE
- From: Raymond DeCampo <nospam@xxxxxxxxxxxx>
- Date: Wed, 17 Aug 2005 14:48:48 GMT
Jonathan Bartlett wrote:
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
-- XML is the programmer's duct tape. .
- References:
- JNDI and J2EE
- From: Jonathan Bartlett
- JNDI and J2EE
- Prev by Date: 16 components in class file
- Next by Date: Re: 16 components in class file
- Previous by thread: JNDI and J2EE
- Next by thread: JWSDP
- Index(es):
Relevant Pages
|
