George Sexton wrote:
From a purely practical standpoint, that would be terribly complicated.
Mod_webapp would have to read and fully understand the web.xml and all of
the servlet mappings. This is made even more impossible by the addition of
filters to the Servlet API. How can mod_webapp even begin to guess at the
hidden logic contained within a filter? It is totally impossible. It's not
clear to me that you could feasibly implement this kind of front end and
incur less overhead that simply passing the request to the servlet engine.
Even if you could, at the end of the day, it would still be non-compliant
because the last sentence of the second paragraph of section 3.1 of the
Servlet API 2.3 Spec says:
"all requests that begin with the /catalog request path, known as the
context path, are routed to the web application associated with the servlet
context."
I quoted this exact spec to a client because they wanted to do what you
propose, only their engine is not smart enough to parse the web.xml. they
wanted me to rename all of my pages to end in ".jsp" so that it would get
forwarded.
To be compliant, the spec must be fulfilled. ALL requests for the context
path must be forwarded to the application. To do otherwise is not compliant
with the spec. A specification is like a map through a mine field. You must
do precisely what it says, without expansion, or interpolation. If you do
otherwise, you will at the least blow your foot off. In our case, by
scrupulously following the spec, we have an application that has been tested
on 6-8 servlet engines with only one small tweak to work around a bug in one
of them.
Deviation from the specification, even in the name of imagined efficiency is
not acceptable. This is particularly true of Tomcat since it has the role of
"Reference Implementation".
From my experience JkMount directice of mod_jk is simpler to use in real
environment when you want to split load between Apache and Tomcat, one
handling static/php and the other servlet/jsp.
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
