But I do have multiple environments.
How do you manage the different configuration files for the different
environments?
Do they have different names and the application figures out which environment
it's on and then uses the appropriately named configuration file? I tried
that; it's too fragile.
Or do the configuration files have the same name on all environments and you
have to ensure that the right ones are installed? That's what I'm using now
with symbolic links. For example, db.properties is what the app uses but it's
a symbolic link to db-dev.properties.
Geoffrey Wiseman wrote:
On Fri, Nov 7, 2008 at 3:45 PM, Rusty Wright <[EMAIL PROTECTED]> wrote:
What are the pros and cons for this?
I feel more comfortable having everything in the war file, because then if
I change one of the properties files all I have to do is rebuild, check the
war file in to subversion, then our release management people check it out
on the appropriate layer. If the properties file was external then that's
another file for them to have to deal with.
It seems less error prone when the war file is completely self contained.
If you've only got one environment or the configuration isn't environmental,
I'd agree; if you're likely to have more than one environment and
environmental configuration, then I'd argue for configuration to be
externalized, so that one WAR can live in testing, staging and production
(or whatever your needs are for multiple environments -- such as multiple
clients) without needing to be changed and rebuilt.
- Geoffrey
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
