Re: JNDI vs. web.xml

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?