JNDI vs. web.xml

Discussion in 'Java' started by markspace, Oct 27, 2010.

  1. markspace

    markspace Guest

    I'm seeing a lot of discussion lately about using JNDI for "loose
    coupling" and binding clients in applications. I'm curious why JNDI is
    regarded as superior to just using configuration parameters in something
    like a web.xml file.

    (Instead of web.xml, you can assume any ad-hoc configuration file. And
    I'm not as familiar with EAR files and their configuration, so I'm just
    choosing a simple, well known example of a configuration file, web.xml.)

    To me it seems like servlet parameters in a web.xml file would work
    exactly in the same was as JNDI look up. The servlet parameters are
    injectable, there's a naming convention that has to be managed. (I.e.,
    if your JNDI is "comp/env/jdbc/myDB", your init parameters could use a
    similar convention). And over all the two technologies seem to do
    similar things.

    Calling "classForName" on an init parameter isn't very difficult, though
    it does require some work, and on the JNDI side there's a bunch on new
    classes to manage, JNDI configuration to manage and new APIs to learn.
    It looks a bit like a wash to me.

    With JNDI seeming to get more popular, I assume that there's real
    benefit to it. But I don't think I've figured out exactly what. Would
    anyone like to provide some thoughts? What are the advantages of JNDI
    in your opinions?
    markspace, Oct 27, 2010
    #1
    1. Advertising

  2. On 2010-10-27 17:37:45 -0400, markspace said:

    > I'm seeing a lot of discussion lately about using JNDI for "loose
    > coupling" and binding clients in applications. I'm curious why JNDI is
    > regarded as superior to just using configuration parameters in
    > something like a web.xml file.
    >
    > (Instead of web.xml, you can assume any ad-hoc configuration file. And
    > I'm not as familiar with EAR files and their configuration, so I'm just
    > choosing a simple, well known example of a configuration file, web.xml.)
    >
    > To me it seems like servlet parameters in a web.xml file would work
    > exactly in the same was as JNDI look up. The servlet parameters are
    > injectable, there's a naming convention that has to be managed. (I.e.,
    > if your JNDI is "comp/env/jdbc/myDB", your init parameters could use a
    > similar convention). And over all the two technologies seem to do
    > similar things.
    >
    > Calling "classForName" on an init parameter isn't very difficult,
    > though it does require some work, and on the JNDI side there's a bunch
    > on new classes to manage, JNDI configuration to manage and new APIs to
    > learn. It looks a bit like a wash to me.
    >
    > With JNDI seeming to get more popular, I assume that there's real
    > benefit to it. But I don't think I've figured out exactly what. Would
    > anyone like to provide some thoughts? What are the advantages of JNDI
    > in your opinions?


    This is not an either/or question. JNDI (specifically, the
    java:comp/env namespace) is the namespace for both externally-managed
    configuration values and in-application container-managed objects.

    If you're using the EE dependency injection tools, you don't *have* to
    write all of the Class.forName glue yourself, and the things injected
    to you may have container integration features like transaction
    management bolted on for you without much further work. If that's
    useful, by all means, use it; if it's not, you already understand how
    to handle your own wiring.

    There are definitely some benefits to not littering every class with
    object-creation logic, by whatever means you achieve that. Embedded
    'new' or 'Class.forName' or 'getInstance()' calls all bind the client
    class to the specific provider at compile time in a way that various
    dependency injection techniques do not.

    -o
    Owen Jacobson, Oct 28, 2010
    #2
    1. Advertising

  3. markspace

    Arne Vajhøj Guest

    On 27-10-2010 17:37, markspace wrote:
    > I'm seeing a lot of discussion lately about using JNDI for "loose
    > coupling" and binding clients in applications. I'm curious why JNDI is
    > regarded as superior to just using configuration parameters in something
    > like a web.xml file.
    >
    > (Instead of web.xml, you can assume any ad-hoc configuration file. And
    > I'm not as familiar with EAR files and their configuration, so I'm just
    > choosing a simple, well known example of a configuration file, web.xml.)
    >
    > To me it seems like servlet parameters in a web.xml file would work
    > exactly in the same was as JNDI look up. The servlet parameters are
    > injectable, there's a naming convention that has to be managed. (I.e.,
    > if your JNDI is "comp/env/jdbc/myDB", your init parameters could use a
    > similar convention). And over all the two technologies seem to do
    > similar things.
    >
    > Calling "classForName" on an init parameter isn't very difficult, though
    > it does require some work, and on the JNDI side there's a bunch on new
    > classes to manage, JNDI configuration to manage and new APIs to learn.
    > It looks a bit like a wash to me.
    >
    > With JNDI seeming to get more popular, I assume that there's real
    > benefit to it. But I don't think I've figured out exactly what. Would
    > anyone like to provide some thoughts? What are the advantages of JNDI in
    > your opinions?


    I would consider web.xml and JNDI more to complement each other
    than replace each other.

    web.xml JNDI

    only web container general, mostly used in EJB container
    static value dynamic value
    simple types complex types
    single war scope can have multiple war/jar/ear scope
    only local access possible remote access
    simple concept can be a bit complex

    Arne
    Arne Vajhøj, Oct 28, 2010
    #3
  4. markspace

    Tom Anderson Guest

    On Wed, 27 Oct 2010, markspace wrote:

    > I'm seeing a lot of discussion lately about using JNDI for "loose coupling"
    > and binding clients in applications.


    May i ask where? I've had some thoughts on this rolling round in my head
    for a year or so, but i didn't know anyone else cared.

    > I'm curious why JNDI is regarded as superior to just using configuration
    > parameters in something like a web.xml file.
    >
    > To me it seems like servlet parameters in a web.xml file would work
    > exactly in the same was as JNDI look up. The servlet parameters are
    > injectable, there's a naming convention that has to be managed. (I.e.,
    > if your JNDI is "comp/env/jdbc/myDB", your init parameters could use a
    > similar convention). And over all the two technologies seem to do
    > similar things.
    >
    > Calling "classForName" on an init parameter isn't very difficult, though
    > it does require some work, and on the JNDI side there's a bunch on new
    > classes to manage, JNDI configuration to manage and new APIs to learn.
    > It looks a bit like a wash to me.


    The big difference that springs to mind - assuming i've understood this
    right - is that JNDI gives you objects, whereas init-params and
    Class.forName gives you classes. JNDI lets you wire up an actual object
    graph declarative-ishly, whereas if you're passing class names in to
    components, the best each component can do is build an instance of that
    class that isn't shared with anything else. There's no way to build object
    graphs.

    For example, say you're writing the new Facebook, and you want to wire
    several servlets to a common UserRegistry object. With JNDI, you set it up
    and bind it somewhere, and the servlets can all get to it. How do you do
    that with init-params? It's going to involve static variables somehow.

    As you say, though, it's much more of a pain to work with JNDI than
    env-entries. What we could do with is some sort of simple wrapper round
    JNDI, so my servlet can go:

    UserRegistry users = (UserRegistry) new JNDIHelper().resolveName("/org/newfacebook/UserRegistry");

    And get what it needs.

    tom

    --
    The powers that are at work here are immensly strong, and extremely
    difficult to comprehend. -- Pete
    Tom Anderson, Oct 28, 2010
    #4
  5. markspace wrote:

    > With JNDI seeming to get more popular, I assume that there's real
    > benefit to it. But I don't think I've figured out exactly what. Would
    > anyone like to provide some thoughts? What are the advantages of JNDI
    > in your opinions?


    IMHO there are two main advantages:
    1. The configuration can be _external_ to the application (IOW you can
    package your war document config params and nobody will have to modify its
    contents - you could even sign it)
    2. The configuration can be _dynamic_ - parameters can change without the
    need to restart you app.

    --
    Michal
    Michal Kleczek, Oct 28, 2010
    #5
  6. markspace

    Lew Guest

    markspace wrote:
    >> I'm seeing a lot of discussion lately about using JNDI for "loose
    >> coupling" and binding clients in applications. I'm curious why JNDI is
    >> regarded as superior to just using configuration parameters in something
    >> like a web.xml file.
    >>
    >> (Instead of web.xml, you can assume any ad-hoc configuration file. And
    >> I'm not as familiar with EAR files and their configuration, so I'm just
    >> choosing a simple, well known example of a configuration file, web.xml.)
    >>


    But that's how it's done already! You're asking for the status quo.

    For example, with Tomcat I set up the JNDI in the context.xml file for the
    application, echoed as "resource-ref" or "resource-env-ref" elements in the
    web.xml:

    <http://tomcat.apache.org/tomcat-6.0-doc/jndi-resources-howto.html>

    In the case of JPA we add persistence.xml to the mix.

    >> To me it seems like servlet parameters in a web.xml file would work
    >> exactly in the same was as JNDI look up. The servlet parameters are


    The web.xml (and related) elements already exist to set up your JNDI lookups.

    >> injectable, there's a naming convention that has to be managed. (I.e.,
    >> if your JNDI is "comp/env/jdbc/myDB", your init parameters could use a
    >> similar convention). And over all the two technologies seem to do
    >> similar things.
    >>
    >> Calling "classForName" on an init parameter isn't very difficult, though
    >> it does require some work, and on the JNDI side there's a bunch on new
    >> classes to manage, JNDI configuration to manage and new APIs to learn.
    >> It looks a bit like a wash to me.
    >>
    >> With JNDI seeming to get more popular, I assume that there's real
    >> benefit to it. But I don't think I've figured out exactly what. Would
    >> anyone like to provide some thoughts? What are the advantages of JNDI in
    >> your opinions?


    Arne Vajhøj wrote:
    > I would consider web.xml and JNDI more to complement each other
    > than replace each other.
    >
    > web.xml JNDI
    >
    > only web container general, mostly used in EJB container
    > static value dynamic value
    > simple types complex types
    > single war scope can have multiple war/jar/ear scope
    > only local access possible remote access
    > simple concept can be a bit complex


    JNDI and web.xml sure are complementary, since web.xml is involved in setting
    up the JNDI context.

    --
    Lew
    Lew, Oct 28, 2010
    #6
  7. markspace

    markspace Guest

    On 10/27/2010 2:37 PM, markspace wrote:

    > I'm seeing a lot of discussion lately about using JNDI for "loose
    > coupling" and binding clients in applications. I'm curious why JNDI is
    > regarded as superior to just using configuration parameters in something
    > like a web.xml file.



    I wanted to say thanks for the input to those replied. There were some
    good insights. I'm kinda pressed for time right now for individual
    replies. I hope to ask a few more questions or add some comments this
    weekend.

    Thanks again to all!
    markspace, Oct 29, 2010
    #7
    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. dhek bhun kho

    Resin/JNDI: object lifecycle

    dhek bhun kho, Jul 2, 2003, in forum: Java
    Replies:
    0
    Views:
    1,563
    dhek bhun kho
    Jul 2, 2003
  2. Mike S
    Replies:
    0
    Views:
    23,000
    Mike S
    Sep 16, 2004
  3. Mick
    Replies:
    2
    Views:
    9,525
    Marcin Grunwald
    Feb 23, 2005
  4. sickness
    Replies:
    0
    Views:
    4,600
    sickness
    May 19, 2006
  5. Erik Wasser
    Replies:
    5
    Views:
    445
    Peter J. Holzer
    Mar 5, 2006
Loading...

Share This Page