Bug 53783 - Static resources and jsp files under WEB-INF/lib/*.jar!/META-INF/resources are not found
Static resources and jsp files under WEB-INF/lib/*.jar!/META-INF/resources ar...
Status: RESOLVED FIXED
Product: Tomcat 7
Classification: Unclassified
Component: Catalina
7.0.29
PC All
: P2 enhancement (vote)
: ---
Assigned To: Tomcat Developers Mailing List
:
Depends on:
Blocks:
  Show dependency tree
 
Reported: 2012-08-27 13:32 UTC by Violeta Georgieva
Modified: 2012-08-27 18:58 UTC (History)
0 users



Attachments
Example (1.34 KB, application/x-zip-compressed)
2012-08-27 13:32 UTC, Violeta Georgieva
Details
Patch proposal (1.20 KB, patch)
2012-08-27 13:32 UTC, Violeta Georgieva
Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Violeta Georgieva 2012-08-27 13:32:16 UTC
Created attachment 29283 [details]
Example

Hi,

According to Servlet Specification, Servlet container should serve static resources and jsp files, located in META-INF/resources in any jar file under WEB-INF/lib.

"
10.5  Directory Structure
A Web application exists as a structured hierarchy of directories. The root of this hierarchy serves as the document root for files that are part of the application. For example, for a Web application with the context path /catalog in a Web container, the index.html file at the base of the Web application hierarchy or in a JAR file inside WEB-INF/lib that includes the index.html under META-INF/resources directory can be served to satisfy a request from /catalog/index.html. If an index.html is present both in the root context and in the META-INF/resources directory of a JAR file in the WEB-INF/lib directory of the application, then the file that is available in the root context MUST be used.
"

When requesting such static resource/jsp file, Tomcat returns 404 Not Found.

Example is attached.
Request:
http://localhost:8080/test-meta-inf-resources/test.jsp
http://localhost:8080/test-meta-inf-resources/meta_inf_resource.jsp

After investigating the issue I think that the problem is in the following code:
org.apache.catalina.startup.ContextConfig
protected void processResourceJARs(Set<WebXml> fragments) {
...
    if (jar.entryExists("META-INF/resources/")) {
        context.addResourceJarUrl(url);
...
}

When I list the entries in jar, I receive:
INFO: Deploying web application archive C:\apache-tomcat-7.0.29\webapps\test-met
a-inf-resources.war
 META-INF/MANIFEST.MF
 META-INF/resources/meta_inf_resource.jsp

There is no entry "META-INF/resources/"

I would like to propose a patch (attached) with which the request URLs above are working as expected.

Best Regards
Violeta Georgieva
Comment 1 Violeta Georgieva 2012-08-27 13:32:45 UTC
Created attachment 29284 [details]
Patch proposal
Comment 2 Konstantin Kolinko 2012-08-27 14:07:59 UTC
Does specification allow JAR files that do not have directory entries?

1. The "jar" tool always creates entries for directories.
There are no options to omit them,

http://docs.oracle.com/javase/7/docs/technotes/tools/solaris/jar.html

2. The spec says "in the META-INF/resources directory of a JAR file".
There is no such "directory" in this resource.jar.


That said, I am OK with the patch.

For stream access to a jar file (o.a.t.util.scan.UrlJar) the entryExists() method does such iteration internally, so proposed patch would not slow it down.

For random access to a jar file (o.a.t.util.scan.FileUrlJar) the ZIP archive index is read when JAR file is opened and iteration over the index (JarFile.entries()) should not waste much time.
Comment 3 Violeta Georgieva 2012-08-27 17:04:50 UTC
(In reply to comment #2)
> Does specification allow JAR files that do not have directory entries?
> 
> 1. The "jar" tool always creates entries for directories.
> There are no options to omit them,
> 

Eclipse IDE is used for jar creation (project type 'java project' and export artifact jar)
Comment 4 Mark Thomas 2012-08-27 18:43:57 UTC
The JAR spec (nor the ZIP spec) states one way or the other if an entry should be made for a directory - empty or not. On that basis and given the performance impacts described by Konstantin I am OK with this patch.

Fixed in trunk and 7.0.x and will be included in 7.0.30 onwards.
Comment 5 Violeta Georgieva 2012-08-27 18:58:35 UTC
Thanks