jakarta-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Craig R. McClanahan" <cmcclana...@mytownnet.com>
Subject Re: setting config file for web application
Date Thu, 13 Jan 2000 18:33:28 GMT
Jose Alberto Fernandez wrote:

> Ari Halberstadt wrote:
> > Craig wrote:
> > >Ari Halberstadt wrote:
> > >
> > >> How can you specify a config file for a web application without messing
> > >> with the web application's web.xml file? There's the WEB-INF/web.xml file,
> > >>...
> > >
> > >A big piece of the thinking behind web applications, and the "web.xml"
> > >deployment descriptor, is to make the web application as independent of the
> > >environment it runs in as possible.  The result of this line of thinking was
> > >that *everything* (except the context path) is specified in the web.xml file.
> > >Providing a mechanism to access a path to a properties file, as you suggest,
> > >would create a dependency on the external environment that is not currently
> > >present.
> >
> > Except that this line of thinking doesn't work in the real world. It's nice
> > to have a config file that specifies constant things, like the name of the
> > application. But there are also variable parameters, e.g., database
> > connection parameters, whose specific values have nothing whatsoever to do
> > with the application and which cannot be predicted in advance. The whole
> > point of parameters is to allow runtime parameterization, if they could be
> > coded as constants in the code there would be no need for the parameters.
> > Tomcat (and the servlet spec) really needs a way to specify additional
> > variable properties without requiring people to muck around with the
> > application's web.xml file.
> >

Tomcat, or any other server, needs to provide tools that make it easy to install new
applications (and tweak the configuration properties to suit the local environment).
That's one of the places that container providers can compete on value.

Adding access to external properties into the servlet spec creates totally unnecessary
complexity (and reduced portability), due to the variety of possible environments to
deploy into

> I agree completely with you. To suggest that in order to deploy an application I
> have to open the application JAR, play with the descriptors (probably braking
> something else) and then re-jar the whole thing in order to deploy is kind of
> moronic, if we think on shrink-wrap application that we go purchase at Safeway :-)
> It has always been my impression that the specs do not address this issue because
> it is outside of the application itself and depends on the container and tools
> being used for deployment. For example, it the container is tomcat alone,
> deployment info is different that if the container is Apache/tomcat distributed
> across different machines (static files go one place and dnamic stuff goes
> somewhere else).

Yes, that's what installer programs are for.  How many Windows apps would you install
if you had to open the Windows Registry and tweak all the new settings required for
this app?

It's also totally consistent with the role of Deployer being separate from the
Application Developer, and is the same theme that is used for EJB containers and
J2EE-compatible servers.

> However it would be nice to have an extensible basic DTD for what such deployment
> XML should look like. It has to be extensible in order to allow each vendor to
> control their own requirements of their own container.

Configuration of the server itself should be unique to that server.  Configuration of
a web application (i.e. the web.xml file) should be 100% consistent and portable
across all containers that implement a given rev of the servlet spec.


View raw message