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-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
