A JSP that maps to a url-pattern in a jsp-property-group does not return the correct result on calling request.getServletPath(). Instead, this call will always return the property group url pattern minus the trailing '/*'. Example: <url-pattern>/level1/*</url-pattern> A JSP in the directory '/level1/level2/test.jsp' calls request.getServletPath(). The result is '/level1' i.o. '/level1/level2/test.jsp'. This may be related to bug 27664. I will attach a test.war file that demonstrates the described behavior.
Created attachment 10803 [details] Test case for the described behavior.
Well, again, this is normal: the JSP servlet is mapped to the jsp-property-group. Again, very little chance of being fixed for now ;)
Ok, this may be perfectly normal from a code perspective, but it is unexpected behavior that has by now caused me to replace my Servlet2.4/JSP2.0 application for a Servlet2.3/JSP1.2 application. Of course everything will also work using the older specs but I'm looking forward to these issues being fixed in a (hopefully not to remote) future version. And thanks for not closing my bug this time so I'd have to reopen it again ;)
I completely disagree with your two bug reports. Either they are invalid or the specification is broken. The main problem is this sentence: "If at least one <jsp-propertygroup> contains the most specific matching URL pattern, the resource is considered to be a JSP file". This is clearly extremely bad behavior when using wildcard patterns. I am going to veto any attempt to fix these last two "bugs" (with bug 27664) until I am explained why the specification is not broken.
I do not understand the badness of this behavior. If a resource is matched by a jsp-property-group, it should be considered a JSP file. If a resource has the extension .jsp it should be considered a JSP file. What's the difference between these two? If you include directories with the resources that match a url-pattern, this explains bug 27664: a directory is then served as a JSP file, which can not be found, resulting in a 404. However, JSP3.3 states: "A JSP property group is a collection of properties that apply to a set of files that represent JSP pages." Directories are apparently not included in this definition. SRV9.10 states: "The purpose of this mechanism is to allow the deployer to specify an ordered list of partial URIs for the container to use for appending to URIs when there is a request for a URI that corresponds to a directory entry in the WAR not mapped to a Web component." Requests for a directory should result in an attempt to append welcome files to this directory.
The problem is that this jsp-property-group feature is that it conflicts with servlet mapping rules, and forces the JSP implementation to be a mini servlet container in itslef.
Ok, I agree with the fact that this will probably make a mini servlet container of the JSP implementation and that this is undesired. But not fixing this also means that Tomcat is not fully compliant with the spec. This may become a problem when products that Tomcat is integrated into attempt to become J2EE 1.4 compatible. You'll probably be happy to know this is the last thing I will say about this issue.
As I said, I contend that this was not what was intended by the spec authors. Due to the "servlet mapping"-like effect of jsp-property-group, and yet the need to have web server like features and a JSP container (I'm sure in 5 minutes you'll be complaining that directory listings do not work), you need special JSP specific processing in your servlet container (and this processing is relatively complex). To implement jsp-property-group properly, you probably would have to do some mapping hacks, and assign some requests to the JSP servlet (after regular mapping), which is relatively complex (jsp-property-group/url-mapping is not trivial, and you have to do it during request dispatching as well), has a performance cost (similar to filter mapping), and introduces obvious dependencies with JSP. That violates the original design idea of the independence of the servlet and JSP specs.
Reopening so that I can close it as FIXED.