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. Best regards, Konstantin Kolinko --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org