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 jbrekke@wi.rr.com
Wisconsin, USA brekke@apache.org
ekkerbj@yahoo.com
http://www.bloglines.com/blog/jbrekke ekkerbj@gmail.com
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-user-help@jakarta.apache.org
|