Konstantin Kolinko wrote:
2010/6/10 André Warnier <a...@ice-sa.com>:
Let me speak for the OP, and for others like me who do not necessarily write
the applications and filters which they are installing on customer systems.
Sometimes, you have to deal with such third-party modules, which have to be
used e.g. as a servlet filter in conjunction with your own application. And
sometimes, these third-party modules are like they are and you cannot change
their code. And sometimes, they require some site-specific parameters,
which they expect to be in their respective <filter> section inside the
application's web.xml file.
A typical example in my case is authentication servlet filters, which
require for example a domain name or a domain controller address which is
specific to each given customer.
If at the same time you have a customer who insists on receiving war files
for application updates, you're cooked, because you have to build a
customer-specific war file every time.
One suggestion I have in the case of Tomcat - and unfortunately only in the
case of Tomcat - would be an extension mechanism to the web.xml file, which
would allow some form of "include" in the web.xml.
(And maybe this would not be an extension, nor a Tomcat-specific thing, if
XML per se already allowed such things).
Then one could insert in web.xml something like this :
...
Servlet 3.0 defines support for "web fragments". Already implemented
in Tomcat 7.
That allows to pack servlets + web.xml fragment + static resources or
JSPs in a jar file to be placed in WEB-INF/lib,
and web.xml and resources in your war file will take precedence over
ones in those jars, allowing you to customize it for your needs.
Konstantin,
if I understand this correctly, then it still means that the fragments
in question are inside the webapp file hierarchy, thus if you create a
war file, these fragments are inside also.
Which leaves the same problem as I explain above, no ?
And to *pid : yes, I know it is not difficult, but it is tedious. And
the point is avoiding the tedious bit. And it makes all the difference
between posting one war file on a website, where all customers can
download it, or creating and posting umpteen individual war files, one
per customer, in individual download directories.
Let me phrase the question another way then.
Assuming that some rogue application or filter *requires* site-specific
parameters in web.xml, normally like so :
...
<init-param>
<param-name>parameter1</param-name>
<param-value>value1</param-value>
</init-param>
<init-param>
<param-name>parameter2</param-name>
<param-value>value2</param-value>
</init-param>
etc..
Does there exist *any* way to put the actual values "value1", "value2",
etc.. in some place *outside* the web.xml file, and *outside* the war
that would be created for this application, and still allow the
application, on startup, to read the values of these parameters "from
web.xml" ?
Like for example :
<init-param>
<param-name>parameter1</param-name>
<param-value>${value1}</param-value>
</init-param>
<init-param>
<param-name>parameter2</param-name>
<param-value>${value2}</param-value>
</init-param>
where "value1", "value2" would be the names of some kind of variables,
defined elsewhere ?
And if yes, is this Tomcat-specific, or servlet-engine-generic ?
And if no, is this because the Servlet Spec explicitly forbids this, or
is it because nobody thought about this before ?
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
