3

We have an enterprise application. Maven build, about 20 submodules with more submodules. We have a dedicated Ops (operations) which deploys our application to 10 clusters. Installations are running different versions, about 5 customers total. Language Java. We are actively developing all parts of the application so everything can change (we are not in maintenance mode). Application is run in Tomcat, in Linux; deployed in Java war files.

At the moment all application configuration (db hosts, etc.) is maintained in Java properties files. These files are located at the global path /opt/app/conf. This is good for ops because they can easily change the configuration of one particular installation. However, for the developers it is difficult because the properties are not stored in our version control repository. It also creates a hard coded "dependency" on a global path which means it is difficult for a developer to have several copies of the repository (or branch) at the same time. Also, sometimes the properties files are not "in sync" with the code (since they are not together in VCS).

We have considered several alternatives to this situation but most of them would clearly favor either ops or dev, not both. Any ideas?

9

Use a tiered approach (not all tiers are necessary):

  1. Load base properties from classpath.
  2. Override with properties from /opt/app/conf, IFF such a file exists.
  3. Override with properties from $HOME/app/conf, IFF such a file exists.
  4. Override with properties specified using environment variables.

You could also use variations on this approach, such as using an environment variable to specify the location of a properties file.

1

One thing you might want to consider is moving away from war files and running Tomcat as an embedded application. Once you've done this, you can easily solve this problem by making the path to the global config an optional argument to the program. Ops won't need to worry about it and the developers have a simple direct control over what config they want to use.

A lot of problems that plague Java EE applications vanish when you move to embedded mode. It's much less complicated for Ops in particular. The app is either running or it isn't. This also sets you up for containerization quite nicely.

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.