Bug 50802

Summary: Deviation from servlet3 spec concerning resource lookup from META-INF/resources
Product: Tomcat 7 Reporter: Sander Sõnajalg <sander.sonajalg>
Component: CatalinaAssignee: Tomcat Developers Mailing List <dev>
Status: RESOLVED FIXED    
Severity: normal    
Priority: P2    
Version: 7.0.8   
Target Milestone: ---   
Hardware: PC   
OS: Linux   
Attachments: test application to reproduce. extract, deploy the war, make a query to root URL, see the system-out for evidence of standard-deviating behavior

Description Sander Sõnajalg 2011-02-17 13:20:33 UTC
Created attachment 26675 [details]
test application to reproduce. extract, deploy the war, make a query to root URL, see the system-out for evidence of standard-deviating behavior

Hi!

I'm writing you from ZeroTurnaround and we are currently building JRebel integration with new containers aiming to implement the servlet3 standard. I've stumbled on a bug in your implementation that is actually at the very core of the servlet standard and thus quite important, and actually a major issue for our integration.

Namely, i'm copy-pasting you a fragment of the reference javadoc of the servlet3 spec for the method ServletContext#getResourcePaths():

============= SPEC START =================

For example, for a web application containing:

   /welcome.html
   /catalog/index.html
   /catalog/products.html
   /catalog/offers/books.html
   /catalog/offers/music.html
   /customer/login.jsp
   /WEB-INF/web.xml
   /WEB-INF/classes/com.acme.OrderServlet.class
   /WEB-INF/lib/catalog.jar!/META-INF/resources/catalog/moreOffers/books.html
 

getResourcePaths("/") would return {"/welcome.html", "/catalog/", "/customer/", "/WEB-INF/"}, and getResourcePaths("/catalog/") would return {"/catalog/index.html", "/catalog/products.html", "/catalog/offers/", "/catalog/moreOffers/"}. 

============= SPEC END =================


Now run my test-application, you'll discover immediately that Tomcat doesn't respect that standard. getResourcesPath("/catalog") would not return "/catalog/moreOffers" if there were 2 embedded jars containing web-fragments. And even more importantly, had there been a new folder coming solely from a jar's META-INF/resources, this wouldn't get listed with getResourcePaths("/").

Please note that these are important issues! Many frameworks rely on various scanning techniques for recursive resource lookup, and so forth.

I've tested this thing with Tomcat 7.0.6 and 7.0.8, problems are present with both.

(Btw, we've received information about the same problems from users of latest glassfish version as well.. i think they are just re-using this part of tomcat and thus getting the same problems... not sure.)

Thanks a lot if you can have a look at this!
Comment 1 Sander Sõnajalg 2011-02-17 13:25:14 UTC
Mm, i forgot to mention: the static resource serving itself is working okay. If you make queries to URLs "/webstart/test1.txt" and "/webstart/test2.txt" they are okay. Only the getResourcePaths() implementation is faulty.

I know I'm now violating the "one-bug-per-report" rule and you can just ignore this if that's important or whatever, but I've also noticed that when I map my servlet to the root URL in web.xml, all the requests (to WHATEVER urls) are being made against my servlet now, making the DefaultServlet never apply, and thus making my static resources unreachable. Just mentioning.. I haven't read the spec on this, but this behavior doesn't make too much sense for me. :)
Comment 2 Mark Thomas 2011-02-17 13:28:23 UTC
(In reply to comment #1)
> I know I'm now violating the "one-bug-per-report" rule and you can just ignore
> this if that's important or whatever, but I've also noticed that when I map my
> servlet to the root URL in web.xml, all the requests (to WHATEVER urls) are
> being made against my servlet now, making the DefaultServlet never apply, and
> thus making my static resources unreachable. Just mentioning.. I haven't read
> the spec on this, but this behavior doesn't make too much sense for me. :)

Yep. That is as per the spec. Please use the users mailing list if you have any further questions on this and keep this issue for the original problem.
Comment 3 Mark Thomas 2011-02-17 15:38:56 UTC
Thanks for the test case.

This issue has been fixed in trunk and will be in 7.0.9 onwards.