Caldarale, Charles R wrote:
From: André Warnier [mailto:a...@ice-sa.com]
Subject: Re: Configure read/write-access in TomCat
the process by which Tomcat, for each deplayed webapp, first reads
and "processes" the conf/web.xml, then reads and "processes" the
applications WEB-INF/web.xml, and then "merges" both according to
some internal logic, is specific to Tomcat, and is NOT very well
documented at present in the on-line documentation ?
I don't think I'd say it's not well documented, but the documentation is not
sufficiently detailed to cover all possibilities.
Well actually I do.
I'm shocked :-)
- I do not know enough of Tomcat and even Java to write
something coherent and correct
Java knowledge isn't required here.
- I find the process of contributing Tomcat documentation
changes rather overwhelming, technically speaking.
I'd agree it's a bit obtuse for the first-timer.
And whereabout would I find the original Tomcat code which does
this, on the off-chance I might actually understand it enough to
write something not totally wrong ?
I'd start here:
org/apache/catalina/startup/ContextConfig.java
org/apache/catalina/core/StandardContext.java
Or, might the process better be described as :
As Tomcat deploys each web application, it first installs
the default servlet and its associated web.xml descriptor
CATALINA_BASE/conf/web.xml for this web application, then
it overrides this setup by any servlets and descriptor
(application/WEB-INF/web.xml) provided by the application
itself (if any). In case of overlapping or conflicting
settings, the web application specific settings have precedence.
The word "installs" is inappropriate, as is the focus on the default servlet. There are
several servlets defined in conf/web.xml (the DefaultServlet being just one of them), along with quite a
bit of other tidbits such as welcome files and MIME mappings. Deployment does not involve
"installing" servlets, but rather building name space maps to translate URLs into classes,
along with processing all the other junk in web.xml and the <Context> element.
The previous paragraph is right on the spot, to explain why I feel that I am lacking some
baggage here.
I was more thinking of an explanation "for the common man", you know,
sysadmin-like.
But yours has potential. Maybe we could collaborate on this ? Like, you write the real
accurate technical explanation, and I translate into common international English ?
;-)
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
