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?

asked Dec 14, 2016 at 11:52

2 Answers 2

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.

answered Dec 14, 2016 at 12:47
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.

answered Dec 14, 2016 at 16:26

Your Answer

Draft saved
Draft discarded

Sign up or log in

Sign up using Google
Sign up using Email and Password

Post as a guest

Required, but never shown

Post as a guest

Required, but never shown

By clicking "Post Your Answer", you agree to our terms of service and acknowledge you have read our privacy policy.

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.