We used a resource bundle to handle the possibility that we may have locale-specific values in the bundle (like error messages in different languages perhaps). If you are just storing server configurations a property file will work fine. In both cases you would have something like this:
When the build script runs it replaces @envSpecificProperty@ with the proper value. We just use one bundle, but this bundle is altered during the build script run. We could run our build script at a command line that goes something like this:
So within the shell script, it knows which environment it is building. The environment specific values are in this shell script. Although we use the same bundle, this bundle will be in a different location since we have multiple instances of IS installed - so the directory structure has this environment in it like - /opt/wm/qa or /opt/wm/rc. Here’s an example of what the script is doing.
elif [[ $ENV = qa ]]; then
You can use ant to do this as well as do the search and replacing of the bundle. The script could load the values for the different environments from one file containing values for all environments.
As I describe this I’m starting to think that the extended property settings would be much easier! Since you have to store the values you want somewhere, why not within the server instance itself! One argument could be to have all the values in one location instead of having to go to each server to make changes.