«

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?

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

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

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

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

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

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!