I go by the principal of least calls in the middle of the night and tend to keep my configuration in two places: Administrative and Internal.
I externalize some stuff like jdbc connection strings, username, passwords, etc into administrative configuration. These have to change if your environment changes, might be different in different deployments, and maybe shouldn't be known by the software developers. You don't want system administrators calling you if they have to move a deployment or fail over a database or something. I keep hand coded SQL or anything else where you can break the application by tinkering in the internal configuration which is loaded from the classpath. Sometimes its a good idea to expose tuning stuff like thread pool sizes and batch sizes. This violates the phone call rule, but can be a life saver. On the other hand, I can definitely see how it is nice to just check one thing into subversion and let another team deploy it. On Fri, Nov 7, 2008 at 8:10 PM, Geoffrey Wiseman <[EMAIL PROTECTED] > 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 > -- > Geoffrey Wiseman >
