tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From André Warnier>
Subject Re: Configure read/write-access in TomCat
Date Wed, 18 Aug 2010 14:55:35 GMT
Pid wrote:
> On 18/08/2010 14:56, Caldarale, Charles R wrote:
>>> From: André Warnier []
>>> Subject: Re: Configure read/write-access in TomCat
>>> The conf/web.xml is the web.xml for the "default servlet".
>> It's a bit more than that, actually.  The contents of conf/web.xml are logically
merged into a webapp's own WEB-INF/web.xml when the webapp is deployed.  Changing conf/web.xml
effectively changes every deployed webapp, which is rarely desirable.
> N.B.  It's well commented and worth reading.

Would you gurus mind pointing out where exactly ?

I am looking at the online documentation of Tomcat 7, at,
and not finding it.

I am also having trouble finding it in the Servlet Specifications v 3.0
(I mean specifically where it says that the "default" web.xml is being merged with the 
application-specific web.xml.)

If you refer to the content itself of the conf/web.xml file, here is all it has to say :

<!-- ======================== Introduction ============================== -->
   <!-- This document defines default values for *all* web applications      -->
   <!-- loaded into this instance of Tomcat.  As each application is         -->
   <!-- deployed, this file is processed, followed by the                    -->
   <!-- "/WEB-INF/web.xml" deployment descriptor from your own               -->
   <!-- applications.                                                        -->
   <!--                                                                      -->

For example, it does not clearly speak of merging, nor in case of merge which possibly 
overlapping or conflicting directive has precedence (one wopuld presume the webapp, but 
then presumptions are sometimes misleading).

By the way, according to, Tomcat 7 follows the

Servlet Spec 3.0.
But in most of the online documentation, it refers only to earlier versions of the specs,

like here :

And as long that I'm at it, following the link "Introduction" on this last page, one comes

to a page (, where the paragraph

"Terminology" is all but enlightening..
(but has been that way since a few versions, so maybe it is I who fails to understand the

subtlety of it's formulation)

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message