Why use JNDI for data sources

Question

Can anyone help explain why JNDI should be a preferred way to expose services such as a database / jms?

The posts I run into all talk about the advantage of not having to load a specific driver manager, benifiting from connection pooling etc. but thats easily achievable by specifying the driver manager in a properties file and using reflection.

Connection pooling can also be achieved by wiring in the right implementation into an application bean via spring or otherwise.

So why would using JNDI be any better?

Answer 1

JNDI really shines when you have to move an application between environments: development to integration to test to production. If you configure each app server to use the same JNDI name, you can have different databases in each environment and not have to change your code. You just pick up the WAR file and drop it in the new environment.

Here are some other assumptions that are crucial to know when judging this answer:

• I don't have access to the servers on which the code is deployed at all, except for read-only access to logs.
• The person who writes and packages the code is not the same person who configures and manages the server.
• Once a WAR file starts on its journey to PROD it cannot be changed again without going back to the beginning. Any testing that's done by QA on the test server must be re-done if the WAR is altered.

Perhaps you don't see this benefit because you're a lone developer who writes code on a local desktop and deploys right to production.

Answer 2

I think the "preferred" mechanism is the one that's preferred by the person doing the admin and configuration. As duffymo pointed out, it's crucial that the configuration be external to your deployable artifact, but otherwise, I'd say anything goes. If your sysadmin prefers using a GUI to configure JDNI entries, cool. If he/she prefers editing properties files with cssh and vi, cool too. If you're responsible for both developing and configuring/deploying your app, then that's pretty much your call. Personally, I like to keep as much implementation as possible inside my artifact, meaning that my data source and drivers live there, too.

If you're asking about technical benefits of JNDI over the alternatives, I'm not sure there are any, but you might want to clarify your question.