Actually Glassfish does not differentiate between implicit and explicit
mappings. There's just a test on the servlet-name : When determining the
wrapper to use for a welcome file, if the physical file is not found, it checks
for servlet mappings. If there's such a match, it also checks that the servlet
name is different from jsp (overridable by a System property).
their source is here :
https://grizzly.dev.java.net/source/browse/grizzly/trunk/code/modules/utils/src/main/java/com/sun/grizzly/util/http/mapper/Mapper.java?view=markup
I believe we could do the same hack in tomcat 7. The spec might not be very
clear but that behavior avoids big surprises for current applications...
Sylvain
On 18 oct. 2010, at 02:35, Mark Thomas wrote:
On 17/10/2010 22:58, Caldarale, Charles R wrote:
From: Mark Thomas [mailto:ma...@apache.org]
Subject: Re: [VOTE] Release Apache Tomcat 7.0.4
There are no matches for the static files so all is
OK for the first sentence. However there is a match
(to *.jsp) the second time through so Tomcat passes
/catalog/products/default.jsp to the JSP servlet
which returns a 404.
This might be the crux of the matter: section 12.2.1 of the spec states that
*.jsp is an /implicit/ mapping (unless overridden by the webapp), and the
second matching protocol in 10.10 seems to be referring to /explicit/
mappings (my interpretation, not definitive in the spec). Tomcat does not
differentiate between implicit and explicit mappings, whereas the other
containers seem to do so.
Implicit seems to be a term used in section exclusively 12.2.1 (OK apart
from a single mention in 12.1). It isn't used elsewhere in the Servlet
spec so it isn't at all clear what - if any - special treatment implicit
mappings are meant to have.
12.2.1 doesn't mention *.jspx which doesn't give me a great deal of
confidence in the completeness or correctness of that section.
Something else that requires some clarity for Servlet 3.1. I'll add it
to my list.
My previous suggestion regarding a new config option would at least
allow users to control this behaviour until we get some clarity in the spec.
Mark
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
