Re: JNDI vs. web.xml
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