Kitching Simon wrote:

> 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 best place to address your suggestions and comments in this regard is
"[EMAIL PROTECTED]".

>
> 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).
>

The deployment descriptor approach is not unique to servlets and JSP pages -- it
is consistent across all the components of a J2EE server.  Most of the app
server's I've seen offer some sort of "deployment tool" that lets you perform
customizations like this as you deploy an application.

Tomcat currently doesn't have such a thing.  I think that would be a
tremendously useful gadget to build.  It would also solve (for Tomcat) the
problems you describe below.

>
> 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....
>

Ah, you've just built your own custom "deploy tool"  :-).

A nice Swing-based GUI that did this kind of thing would sure be more pleasant.

>
> Regards,
>
> Simon

Craig



---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]

Reply via email to