My experience is that having one artifact that will work on any
deployment lets you focus on the project, not the configuration. We now
have a testing, beta, and production tomcat setup, each once setup with
the correct jndi properties for our application ( we use
commons-configuration ) at each level. This way, we produce one
artifact ( war ) that can be deployed to all environments.
If your build system uses ant or maven to generate configuration, then
if your configuration changes, you need to rebuild/deploy those changes.
In our case, that was too slow.
Using commons-configuration, we use property files in our war as
defaults, then any container may redefine or define any property
specific to the container we've deployed into ( like beta,test, or
production ). We've used this setup with just settings ( string, ints,
etc ) or jdbc connection pools/resources.
James Carman wrote:
If you make your build system smart enough, you can have it generate
your context.xml file with the correct settings (Velocity comes in
handy here) depending upon your targeted environment (test vs. prod).
I usually do this using a build.properties file in Ant. In order to
change your targeted environment, all you have to do is change the
build.properties file and that's it.
--
=====================================================================
Jeffrey D. Brekke [EMAIL PROTECTED]
Wisconsin, USA [EMAIL PROTECTED]
[EMAIL PROTECTED]
http://www.bloglines.com/blog/jbrekke [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
