tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Kitching Simon <>
Subject RE: Setting properties outside of the WAR
Date Wed, 03 Jan 2001 10:07:32 GMT
I think that this whole issue (specifying configuration parameters
to web applications) needs some serious thought - possibly
at the level of the servlet spec development group, even.

The problem is that two deployments of the same application are
not necessarily identical. The most obvious example is where two
otherwise identical installations need to be configured to use
different databases (ie different JDBC connection strings).

It is really **nasty** to deploy a webapp, then have to edit a string
inside the WEB-INF/web.xml as part of the deployment procedure.
(a) it's hard to describe in such a way that an "application support team"
can reliably get it right,
(b) if it is stuffed up, then really nasty consequences can occur
- testing system gets connected to production database, or 
  production system gets connected to development database,
  which is worse ???!!

I think what is needed, instead, **is** some configuration 
outside of the webapp. Upgrading a webapp then doesn't
"throw away" the configuration settings used for the previous
release. Obviously, there needs to be some kind of consistency
checking to ensure that new configuration items don't need to
be added for the new release, etc.

My current solution (which you are welcome to, Ritchie, if you
want a copy) is a perl script which is run after installing a copy
of the webapp. It searches the tree of files, replacing any occurrence
of strings of form @token-name@ with a value from a property file
which is specific to each *installation* of the webapp. My development
installation of the webapp gets configured using one property file,
my acceptance-test instance uses a second, and the production
system uses a third properties file.

While the *main* file that gets modified during the install is the
web.xml file, there are other files that get modified, eg the log4j
configuration options file which is also in WEB-INF.

Note that I do not want to use ANT to do this token-replacement
during building of the "WAR" file, because I want to have a standard
WAR file that can be deployed into development, testing and production.

Any alternatives that could be used to configure a webapp per-deployment
would be welcome - I'm not perfectly happy with my current solution, I just
can't think of anything better....


> -----Original Message-----
> From:	Craig R. McClanahan []
> Sent:	Tuesday, January 02, 2001 10:10 PM
> To:
> Subject:	Re: Setting properties outside of the WAR
> Ritchie Young wrote:
> > Thanks for the response but that wasn't quite what I was getting at.
> >
> > The idea was that there should be some easy way for an administrator to
> set
> > a property for the application. It just strikes me that the
> > variable is a slightly cumbersome way especially when there start to be
> a
> > few more applications.
> >
> > I thought that the "Context" tag in server.xml wouldn't be a bad place
> to
> > incorporate application specific settings such as where the application
> can
> > find it's properties file. This would also allow for multiple instance
> of
> > the same application to use different configurations but only one WAR
> file.
> >
> The settings in server.xml are designed to configure Tomcat's own features
> --
> not your application.  Your app is responsible for that.  You can do
> things in a
> portable way (for example, call
> ServletContext.getResource("/WEB-INF/")), or not, as you
> choose.
> Keep in mind that the intent of web applications is that they are *stand
> alone*
> gadgets, to be dragged and dropped onto a servlet container (*any*
> container,
> not just Tomcat) and work correctly.  Given that, it does not make sense
> for the
> servlet API to provide any mechanism to access resources outside of the
> WAR.
> You are free, of course, to implement any such technique (such as passing
> the
> absolute pathname to a properties file in a servlet initialization
> parameter),
> but you are making it harder on people who want to deploy your webapp in a
> variety of environments, as well as limiting the set of environments in
> which
> your app can run (for example, an ISP might prohibit file access in order
> to
> protect the various web apps from each other).
> >
> > Cheers
> > Ritchie
> >
> Craig McClanahan
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, email:

View raw message