commons-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "James Carman" <>
Subject Re: [configure] - context.xml vs Tomcat Admin
Date Tue, 23 Jan 2007 12:14:46 GMT
The paranoid point of view can be a good thing.  So far, though, it
has worked for us.  We just have different "flavors" of our file for each of our environments.

On 1/22/07, Craig McClanahan <> wrote:
> On 1/22/07, James Carman <> wrote:
> >
> > "Using the server admin lets you take the same web application
> > and deploy it *unmodified* in different environments where you really
> > want to connect to different services (such as a testing server, a
> > staging server, and a production server)."
> >
> > 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.
> Sure, you can do a lot more work in your build script if you want to :-).
> But, I have also seen lots of big shops that are totally allergic to testing
> one version of an app but then needing to build it again before deployment.
> They want to be sure the bits they test are *exactly* the bits that are
> actually deployed.  For this scenario, having an ability to configure
> resources externally is extremely valuable.
> Come to think of it, this is very similar to the attitude we have in Apache
> projects, where a proposed release needs to have the actual bits we are
> voting on (versus a promise to build from a particular SVN tag or revision
> number later on).
> Craig

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

View raw message