asteri
asteri

Reputation: 11572

Why use JNDI context if it irrevocably ties you to Tomcat?

Everyone seems to say that you should use Tomcat's JNDI contexts to manage your JDBC connections and drivers and so forth. And after reading over the documentation, I understand the draw. But if you use it, your application must use a Tomcat container from now until the end of time. Isn't it a bad programming practice to make your application rely on such an environment configuration (especially for Java, which is supposed to be "Write Once, Run Anywhere")? How is this not a dangerous development decision?

Upvotes: 0

Views: 82

Answers (2)

gknicker
gknicker

Reputation: 5569

Isn't it a bad programming practice to make your application rely on such an environment configuration (especially for Java, which is supposed to be "Write Once, Run Anywhere")?

Yes, in general. However, this design provides several benefits, including managed connection pooling and abstracting the database connection configuration from your application. JNDI itself is a directory service abstraction which protects you from directory API differences.

How is this not a dangerous development decision?

Using JNDI to manage JDBC connections is not specific to Tomcat. Every Java application server (GlassFish, Oracle, WebSphere, etc.) does this. So you're not tying yourself to Tomcat, just to Java.

See also: Using JNDI for Database connections

Upvotes: 3

dunni
dunni

Reputation: 44535

I don't know which documentation you read, but if you use JNDI, the only thing which you specify in the application, is the JNDI name of the resource you want to use (e.g. for the DB connection). Everything else is configured in the container and not part of your application (like URL of the DB, username, password etc.).

Upvotes: 2

Related Questions