tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
Subject DO NOT REPLY [Bug 50802] New: Deviation from servlet3 spec concerning resource lookup from META-INF/resources
Date Thu, 17 Feb 2011 18:20:39 GMT

           Summary: Deviation from servlet3 spec concerning resource
                    lookup from META-INF/resources
           Product: Tomcat 7
           Version: 7.0.8
          Platform: PC
        OS/Version: Linux
            Status: NEW
          Severity: normal
          Priority: P2
         Component: Catalina

Created an attachment (id=26675)
 --> (
test application to reproduce. extract, deploy the war, make a query to root
URL, see the system-out for evidence of standard-deviating behavior


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:


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

============= 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

(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!

Configure bugmail:
------- You are receiving this mail because: -------
You are the assignee for the bug.

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message