When to put configuration in file.properties or Jndi

Question

For a long time in many IT services, I see some complex process to manage Java EE application configuration depending of the environments: - custom tools, with Database or not, to manage replacement in the properties file (unzip war, replace, zip war...) - Externalize properties file in obscure directory in the server (and some process to update it some time) and some time with a JNDI configuration... - maven profile and lot of big properties files

But for database connection everybody use jndi datasource.

Why this is not generalized for all configurations that depend of environment ?

Update : I want deal with other variable than datasource, there is no question about datasource : it's in configured in JNDI for Java EE application. After if you want hack JNDI...

Answer 1

Setting up database connectivity (like user name, password, URL, driver etc.) somewhere in the application server has several advantages over doing it yourself in the WAR:

• The app server can be a central point where the DB is configured, and you might have several WARs running on that server sharing a DB. So you need to set it up only once.
• The DB settings, especially the credentials (username, password) are stored somewhere in the app server instead of somewhere in the WAR. That can have security implications (for instance, restricting access to that file is easier done than in a WAR archive).
• You can set up one JNDI path to retrieve a DataSource instance pointing to the DB and do not need to worry about username and password anymore. If you have multiple app servers (one live system, one test system, several developer machines) with different DB URLs and credentials, then you can just configure that in each app server individually and deploy the WAR files without the need to change DB settings (see below).
• The server might provide additional services, like connection pools, container managed transactions, etc. So again, you don't have to do it on your own in the WAR.

This is true for other services provided by the app server as well, for example JavaMail.

There are other cases where it you want to configure something that is specific to one web application and does not rely on the environment (the app server), like logging (although that may be set up in the app server, too). In those cases you might prefer using static config files, for instance log4j.properties.

---

I want to illustrate the third bullet point a bit further ...
Suppose you have one WAR in three app servers (developer machine, test server, live server).

Option 1 (DB setup in WAR)

Create a database.properties :

db.url=jdbc:mysql://localhost:3306/localdb
db.user=myusername
db.pass=mysecretpassword

#db.url=jdbc:mysql://10.1.2.3:3306/testdb
#db.user=myusername
#db.pass=mysecretpassword

#db.url=jdbc:mysql://10.2.3.4:3306/livedb
#db.user=myusername
#db.pass=mysecretpassword

Before you deploy it somewhere, you need to check if your settings are pointing to the right DB!

Also, if you check this file in to some version control system, then you might not want to publish your DB username/password to your local machine.

Option 2 (DB setup in App Server)

Imagine you have configured the three servers with their individual DB settings, and each of them registers the DB with the JNDI path java:database/mydb.

Then you can retrieve the DataSource like so:

Context context = new InitialContext();
DataSource dataSource = (DataSource) context.lookup("java:database/mydb");

This is working on every app server instance and you can deploy your WAR without the need to modify anything.

---

Conclusion

By moving the configuration to the app server you'll have the advantage of separating settings depending on the environment from your app code. I would prefer this whenever you have settings involving IP addresses, credentials, etc.

Using a static .properties file on the other hand is simpler to manage. I would prefer this option when dealing with settings that have no dependencies to the environment or are app specific.