JNDI and J2EE

Discussion in 'Java' started by Jonathan Bartlett, Aug 12, 2005.

  1. 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.

    Jon
     
    Jonathan Bartlett, Aug 12, 2005
    #1
    1. Advertising

  2. 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.
     
    Raymond DeCampo, Aug 17, 2005
    #2
    1. Advertising

  3. Jonathan Bartlett

    burning_hrt

    Joined:
    Apr 9, 2012
    Messages:
    1
    Hi,

    A very good post for understanding the concept of jndi. But m having one more doubt over here..

    I've used this lookup() method in both glassfish 3.1 server and tomcat 7.0. In glassfish, we needed to make one jdbc resource for any database and from the servlet we used to used to get the DataSource back using ctx.lookup("jdbc/Mydb");

    But, when i tried the same concept in Tomcat 7.0, i was forced to use ctx.lookup("java:comp/env/jdbc/Mydb");, otherwise, I was unable to get the DSN.

    I'm unable to understand over here that what actually is wrong...???

    And if possible please explain ENC context..



    Thank you....
     
    burning_hrt, Apr 9, 2012
    #3
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. joes
    Replies:
    0
    Views:
    431
  2. Mike S
    Replies:
    0
    Views:
    23,052
    Mike S
    Sep 16, 2004
  3. Mick
    Replies:
    2
    Views:
    9,602
    Marcin Grunwald
    Feb 23, 2005
  4. Dakota Mon

    J2EE/JNDI problem

    Dakota Mon, Feb 21, 2006, in forum: Java
    Replies:
    2
    Views:
    2,043
    Paulus de Boska
    Feb 21, 2006
  5. Replies:
    2
    Views:
    3,919
Loading...

Share This Page