My application is a generic enterprise application which can be deployed on any application server running on any OS.

I don't know how/where to configure my application, except for the database information which are stored in the application server as datasource.

While it's easy to do, I could use the database as a configuration container, but... the database shouldn't contain the configuration elements: I want to be able to use any database in any environment (dev, test, acceptance, production).

Does Java EE offer any kind of configuration management similar to what is offered to the datasources? If yes, what is it? If not, what is the best practice on this?

I often read the following advice: put these items in a properties file on the server. Fine, but in that case the location to the properties file becomes a configuration item in itself, so where/how do I define the location of that properties file and transmit that info to my application?

1 Answer 1


There are a couple options that present themselves in this case.

The first, is the properties file. Its location is somewhere and typically in the class path. Typically, you will see it coupled with the getResource family of calls.

Properties prop = new Properties();

Now, if you don't have the property file in the classpath, you could specify it in the system properties which can be accessed through the System class as described here.

With the invocation of: java -Dtest="true" -jar myApplication.jar the value can be extracted with: System.getProperty("test") and then used either to specify other resources or being a resource itself. While it isn't immediately visible with many application servers, its still there, somewhere. In Eclipse, you can easily see them by going to the run configuration and look at the VM arguments.

Similar to the system properties, there are the environment properties accessed through System.getenv. The rest of that set of documents is a good read - The Platform Enviroment. While it speaks mostly to Java SE, nearly everything in it is still applicable and an option for Java EE (I don't think you'll be looking at Java Web Start or Java applets).

Moving to the realm of the application server, we get to the names stored in the context of the application or server.

InitialContext ic = new InitialContext();
loc = (String) ic.lookup("java:com/env/app/location");

This value is actually stored in the server configuration itself. The documentation for tomcat. Note that each app server is different and you might get some ugliness in there. The only difference between the database from JNDI and a string is the type that it presents. One is a DataSource, the other is a String.

  • I don't really like the first option as it's hardcoding a configuration element (the configuration file name). I'd prefer to access a variable, just like System.getEnv() allows. Is it me or it makes more sense to use System.getenv() for things actually defined on the server and InitialContext for things linked to other resources? Feb 3, 2016 at 14:37
  • @OlivierGrégoire I've used all of them for different things at different times in different conditions. One server I deploy to I don't have the ability to change the VM, system, or environment settings - and can only deploy there (I can't stick a config file outside of the deployed package). On that server, I have a JNDI setting that is "dev", "test" and "prod" which is then used to load the corresponding "app_"+env+".properties" file from the class path. Another server I worked with had a /prop/... directory where we could deploy text files that was part of the server's class path. ...
    – user40980
    Feb 3, 2016 at 14:41
  • The reason I presented all of these options is that some of them work in some combination in some environments. The essence of them though is "use something you have access to to let you specify the location of the file". The exact combination that you can use depends quite a bit on your server environment, but unless you've got a Mordac locking everything down to absurdity, there is some combination that will work.
    – user40980
    Feb 3, 2016 at 14:45
  • Indeed, I totally understand and agree. I was only giving my feedback to what you wrote. All of these seem valid options, but even though these are valid options, I think some are superior to other of those valid options. This is what I wanted to express in my previous comment. Feb 3, 2016 at 14:52
  • @OlivierGrégoire FWIW, at one place I worked, configuration was stored in a couchDB. This allowed all the servers to work off a single known point. The selection was in the dns resolution. config.dev.company.com vs config.prod.company.com (each server looked in *.{env}.company.com and the code just accessed 'config' for the http request. Furthermore, it made for easy mocking in unit tests to tweak the local configuration. Though that's a bit more of a roundabout way than I'd otherwise suggest.
    – user40980
    Feb 3, 2016 at 15:45

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.