Graham,
That's great advice, and one that I've been pondering in several
environments that I've configured over the years. One interesting thing
about this scenario is that it actually requires discipline beyond that
actual build process / system, but in application design as well. For
instance, the servlet API specifies parameters to be passed to servlets
on init, which complicates this very thing if the parameter value is
environment-specfiic. So it really demands some forethought in
application design to ensure that resource files and/or init values are
late bound, rather than statically bound by config files like web.xml
which by definition a servlet container is going to process.
This is probably why in various places in the Java SDK the use of System
properties (which I personally really don't like, as it dominates the
entire VM instance rather than the object instance) is the means of
setting such variables, as it externalizes these values from the app in
question.
Thanks for the reply Graham -- perhaps I'll blog an example of this soon.
Brad
Graham Leggett wrote:
Brad O'Hearne wrote:
What is the generally accepted convention for handling builds where
there are configuration files whose values are different depending
upon the target platform being built for? For example, I may have a
configuration file with JDBC URLs in it, and these values may be
different depending upon whether I am building for a development
environment, or a testing or production environment. Or, another
example would be variations in web.xml files depending upon whether
the WAR file will be deployed to a dev, test, or production
environment. .
I generally try to avoid this scenario, because it's inevitable at
some point that someone is going to put the test build into production
by mistake, and your test database will become live, or vice versa.
Ideally installation specific config should go in an environment of
some kind external to your build, possibly stored in a separate
repository, or pointed to by environment variables.
In other words, it should be as hard as possible for the wrong config
to go in the wrong place.
Regards,
Graham
--
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
