Environment specific config files - best practices? [closed]

As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance. Close开发者_如何学Pythond 10 years ago.

I have an application with a configuration file which has a lots of environment-specific settings. Also I have a bunch of environments where that application can be deployed.

What are the best practices of making that configuration environment-specific?

Currently I'm adding the directory where the config files are located to the JVM classpath. This way application simply loads the configuration files from the classpath and uses what it finds there.

However, recently I was told that this is a bad practice and that I should consider using JNDI for such purpose.

So, what could you recommend to make the deployment and development processes as painless as possible in my situation?

Thanks in advance.

---

You could allow users to specify the configuration file/directory with whichever of the following appeals to you: (1) a command-line argument; (2) a Java system property; or (3) an environment variable.

Note that you can access the FOO_CONFIG environment variable by calling System.getenv("FOO_CONFIG"). Sun "deprecated" (a euphemism for deliberately broke) this operation between Java 1.0.1 and Java 1.4.x inclusive. However, this operation was undeprecated (that is, fixed) in Java 5.

---

You could set up and maintain specific sets of config files per each environment, in distinct folders under your project root. Then you could extend your build process with a parameter to determine which environment to build for, so that it can copy the required config files into the package to deploy. The deployed app then sees the config files always in the same place, and it has only one consistent set of files, minimizing the chance of errors.

The drawback of this approach is potentially lots of duplication between your config sets. This can be solved by generating the concrete config files as part of the build process. Extract all variable config parameters into distinct config property files, one per each environment, and create a template config file set, which contains placeholder names instead if the real parameters in every applicable place. Then all you need is a preprocessor in your build which creates a set of config files from the temples, replacing the placeholders with the corresponding concrete values. (E.g. Maven has built-in support for properties and profiles, and also for generating resources at build time.)

---

We have similar requirement. This is how we implemented it.

We have shared-app.war file that is shared accross different departments. The code in this .war file looks for (or reads from) shared-app-cfg.properties file. This properties file will be different for each department.

In .war file's manifest we say it depends on shared-app-cfg.jar.
The .war expects shared-app-cfg.jar to be available in runtime environment.
The contents of this .jar file is shared-app-cfg.properties.

Each department will have to build this jar file containing properties file.
Depending on how each department builds their application they can:

1. Package shared-app-cfg.jar with shared-app.war file in an .ear file.

2. Alternatively, put the .jar file in shared-lib.
   Not sure if this is elegant solution... but it solves the issue.

---

IMHO, if you have lot of environment-specific information, you're better off using config files as you already do, had you had only a few strings, you could have used jndi environment strings instead.

---

Another guess (awaiting comments) - is it good practice to put "/configs" string into JNDI and let application load the configs from there? Looks better than adding it to classpath and still fulfills it's purpose pretty well. What do you think?