What is the best practice to deploy database config (username/password) with Java web-app (web.xml)?

Question

I have a Java web-app using standard web.xml and servlets. At the moment, I'm using the <context-param> tags in web.xml to define the database configuration (JDBC url, username, password, etc.). These are picked up by a servlet in its init() method.

But I'd like to not include database username/password in my source repository.

For testing, I'm using jetty-maven-plugin. With that, I specify an option overrideDescriptor with a supplementary web.xml that is applied after the primary web.xml. I put my testing database configuration in this supplementary file, and everything works great.

For deployment, my host is using Tomcat. I'm not sure how to apply a database config here. Is there a similar way to specify a supplementary web.xml file? If not, what is the best practice to do this? Read the configuration from a separate properties file (or similar) included as a resource?

Answer 1

You should be using connection pools and JNDI. You keep the credentials on the server that way. Users only need the JNDI lookup name (e.g., "jdbc/FooDataSource") to access the connection pool.

Answer 2

You could always store the configuration in an external .properties file, change your servlet to read from this instead (perhaps having web.xml point at the path to the file), and thus keep the file only on the server and out of source control.

Answer 3

External property file and make it placed in user's home directory.

Answer 4

"Read the configuration from a separate properties file (or similar) included as a resource?"

Yes.

There are lots of ways to do THAT, too. My current project uses Spring's PropertyPlaceholderConfigurer to read the appropriate properties files and allow any of the values to be used in a context file using the usual ${whatever} notation.

Addition:

Incidentally, we use a custom subclass of PropertyPlaceholderConfigurer to set the locations of the files. We use a "global" properties file that applies to all environments (dev, test, uat, prod) and then one file for each environment that overrides the global settings.

The files themselves are deployed in a jar, but we don't need the flexibility of changing the values on the fly.