commons-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Jeffrey D. Brekke" <>
Subject Re: [configure] - context.xml vs Tomcat Admin
Date Tue, 23 Jan 2007 02:04:24 GMT
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 file in Ant.  In order to
> change your targeted environment, all you have to do is change the
> file and that's it.
Jeffrey D. Brekke                         
Wisconsin,  USA                           

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message