tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Kitching Simon <Simon.Kitch...@orange.ch>
Subject RE: Setting properties outside of the WAR
Date Wed, 03 Jan 2001 17:01:18 GMT
Hi Ritchie (and anyone else interested)

Something else occurred to me after sending this email,
and reading an unrelated email from Craig.

Craig was talking about being able to run a webapp direct
from a WAR file without unpacking it. Yes, the idea sounds
nice, but then how is anyone to configure the webapp? The
web.xml file can't be edited! This implies that the WAR is
built with the necessary attributes already set, but isn't that
like distributing a shrink-wrapped application with all the 
configuration items hard-wired and impossible to change by
the end user???

Anyway, here's the perl script and a few related files.
Documentation is in the comments inside "install.pl".

The code may seem a little odd in places - the install
program is a result of "experimenting" with various 
approaches, and not all the traces of previous
experiments have been removed!

 <<install.pl>>  <<install.cfg>>  <<installTokensExample.cfg>>
 
and here's an example of a file that will be modified during install:
 <<web.xml.install>> 

What I do to distribute an app is build a jar file containing
the install.pl, install.cfg and installTokensExample.cfg files,
and then a subdirectory containing the entire web application.

To install a distribution the first time:
* create an install directory, cd to it
* Unjar the jar
* cp installTokensExample.cfg ../installTokens.cfg (note rename)
* vi ../installTokens.cfg and set specific attributes for that install
* perl install.pl

To upgrade a distribution, ie where a proper installTokens.cfg has
already been created,
* delete the old install directory
* recreate the install directory, cd to it
* unjar the new jar file
* perl install.pl

Any feedback welcome!!!!

Cheers,

Simon

> -----Original Message-----
> From:	Ritchie Young [SMTP:ritchie@mirametric.com]
> Sent:	Wednesday, January 03, 2001 4:30 PM
> To:	tomcat-user@jakarta.apache.org
> Subject:	Re: Setting properties outside of the WAR
> 
> 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
> >
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tomcat-user-unsubscribe@jakarta.apache.org
> For additional commands, email: tomcat-user-help@jakarta.apache.org

Mime
View raw message