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.