tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From André Warnier ...@ice-sa.com>
Subject Re: GlobalNamingResources outside of server.xml
Date Wed, 22 Apr 2009 11:13:43 GMT
Robert Koberg wrote:
> I just finished my first cup of coffee
You must be in a different timezone then. We've had to refill the coffee 
machine a couple of times already.
In any case, thank you for your early interest and for your contribution.

  and realized I didn't address
> having the external def in the conf directory. You probably do not want 
> to rely on each user having the same directory structure, so you can't 
> rely on a hard coded absolute or relative path :)
> 
True.

> First, let me say I usually put a .properties file in some system 
> defined directory and configure at app start up. 
...

Right. I guess this would be the sensible and Servlet Spec compatible 
thing to do in the first place.

Basically, I jumped into this thread because I had a glimpse of a hope 
that the scenario outlined by the OP for (I believe) server.xml, might 
also be applicable for the following kind of practical case, which has 
come up already several times on this list :

I distribute a webapp to customers, as a war file.
In this webapp, are some servlets that I get from third-parties, and 
which need installation-specific settings in the web.xml deployment 
descriptor, settings which are present as <param-name> and 
<param-value>. For example, something like

<param-name>HostToTalkTo</param-name>
<param-value>123.123.45.67</param-value>

Thus, when I send an updated app as a war-file to the customer, this 
customer has to unpack the war-file, edit the web.xml according to their 
specific values, repack the war-file and deploy it on their server.
This is rather messy and unpractical.
I have thus been wondering if there was some clever way by which, 
without changing the way in which these third-party servlets read their 
parameters, one could provide a mechanism that would avoid the 
unpacking/modifying/repacking cycle.

 From what I've read so far, in any case it does not seem simple.
 From what I understand, it would be possible using Xinclude, but that 
would entail
1) somehow to convince the customer's Tomcat's Xerces parser to be 
Xinclude-aware, which to my naive understanding looks complicated to do, 
(and may/may not have side-effects ?)
2) one would need one Xinclude-d text file per param-value, which looks 
kind of clumsy
3) and the path to these Xinclude-d files would need to be fixed, which 
somehow also conflicts with the hoped-for flexibility

So far thus, it looks still pretty much like a forlorn hope.
Any additional ideas anyone ?

A more general question would be whether someone could think of a way by 
which such an added functionality could be added to Tomcat, without 
breaking the Servlet Spec compatibility ?

For example, would it be legal/compatible to have something like
<param-value>${HostToTalkToIP}</param-value>
and have this valuename defined as a variable somewhere else ?


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org


Mime
View raw message