Environment-specific configuration files - best practices?

Question

I have an application with a configuration file that has many settings for the environment. In addition, I have many environments in which this application can be deployed.

What are the best methods to configure this configuration?

I am currently adding a directory in which the configuration files are in the path of the JVM class. Thus, the application simply loads the configuration files from the class path and uses what it finds there.

However, I was recently told that this is bad practice and that I should use JNDI for this purpose.

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

Thanks in advance.

Answer 1

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

Note that you can access the FOO_CONFIG environment FOO_CONFIG by calling System.getenv("FOO_CONFIG") . Sun is "deprecated" (a euphemism for intentional violation) of this operation between Java 1.0.1 and Java 1.4.x inclusive. However, this operation has not been fixed (i.e., fixed) in Java 5.

Answer 2

You can configure and maintain specific sets of configuration files for each environment in different folders under your project root. You can then extend the build process with a parameter to determine which environment it will be created for, so that it can copy the necessary configuration files to the deployment package. Then the deployed application sees the configuration files always in one place and has only one sequential set of files, which minimizes the likelihood of errors.

The disadvantage of this approach is potentially a lot of duplication between your configuration sets. This can be solved by creating specific configuration files as part of the build process. Extract all the configuration parameter variables into separate configuration properties files, one for each environment, and create a set of template configuration files that will contain placeholders instead, if the real parameters are in each applicable place. Then all you need is a preprocessor in your assembly, which creates a set of configuration files from the temples, replacing the placeholders with the corresponding specific values. (For example, Maven has built-in support for properties and profiles, as well as for generating resources at build time.)

Answer 3

We have a similar requirement. So we implemented it.

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

In the manifest of the .war file, we say that it depends on shared-app-cfg.jar .
.war expects shared-app-cfg.jar be available at runtime.
The contents of this .jar file is shared-app-cfg.properties .

Each department will have to create this jar file containing the properties file.
Depending on how each department builds its application, they can:

• The shared-app-cfg.jar with the shared-app.war file in the .ear .

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

Answer 4

IMHO, if you have a lot of information about the environment, you are better off using the configuration files, as you already did, if you had only a few lines, you could use the lines of the jndi environment.

Answer 5

Another suggestion (pending comments) is it good practice to put the "/ configs" line in JNDI and let applications load configurations from there? It looks better than adding it to the classpath and still performs it well. What do you think?