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
