tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Ritchie Young" <ritc...@mirametric.com>
Subject Re: Setting properties outside of the WAR
Date Wed, 03 Jan 2001 15:30:16 GMT
Oh good, it's not just me.

Thanks, I would appreciate it if you did forward me a copy of that script.

Cheers
Ritchie

----- Original Message -----
From: "Kitching Simon" <Simon.Kitching@orange.ch>
To: <tomcat-user@jakarta.apache.org>
Sent: Wednesday, January 03, 2001 6:07 PM
Subject: RE: Setting properties outside of the WAR


> 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....
>
> Regards,
>
> Simon
> > -----Original Message-----
> > From: Craig R. McClanahan [SMTP:Craig.McClanahan@eng.sun.com]
> > Sent: Tuesday, January 02, 2001 10:10 PM
> > To: tomcat-user@jakarta.apache.org
> > 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
> > TOMCAT_OPTIONS
> > > 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/myprops.properties")), 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: tomcat-user-unsubscribe@jakarta.apache.org
> > For additional commands, email: tomcat-user-help@jakarta.apache.org
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tomcat-user-unsubscribe@jakarta.apache.org
> For additional commands, email: tomcat-user-help@jakarta.apache.org
>


Mime
View raw message