For example:
MyApp is a web app that contains a properties file (server.properties) that describes config data (e.g. server names) for the app. In the development phase, server.properties is located in its own IDE project folder (a logical spot for it).
Now it’s time to deploy MyApp. The IDE makes it quite trivial to jar up the class files as well as the supporting config files. Now we just drop the Jar in the appropriate web container and away we go….
A week later… the server config data that MyApp uses needs to change. Which makes more sense?
A. Modify the server.properties file back in IDE land and generate a completely new jar file. Redeploy. (which means bouncing the app for a simple configuration change).
B. Crack open the already deployed Jar and modify the server.properties file? (may have to call a refresh function in MyApp if server.properties is cached… but should not require a full app bounce. Also need to remember to modify source server.properties as well so future deploys don’t revert server.properties to the old server names).
C. Make server.properties external to the jar file in the first place. Very similar to B’s process, with the minor difference of keeping config data external to the jar (introduces different paths between development and production deploys)
D. Other:
Thanks!
I’d go with D.
Try to load the properties files from outside the .jar then, if that fails, load the properties built into the jar.
This lets you push out a “ready made” configuration with each build (also reduces the complexity of a deployment, if by just one file), while also making overriding configurations possible and reasonably simple.