JNDI vs. web.xml

M

markspace

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?
 
O

Owen Jacobson

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
 
A

Arne Vajhøj

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
 
T

Tom Anderson

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
 
M

Michal Kleczek

markspace said:
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.
 
L

Lew

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.

The web.xml (and related) elements already exist to set up your JNDI lookups.
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.
 
M

markspace

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!
 

Ask a Question

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

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

No members online now.

Forum statistics

Threads
473,744
Messages
2,569,484
Members
44,903
Latest member
orderPeak8CBDGummies

Latest Threads

Top