Bug 49721 - Fail to access the resources such as jsp files from a jar file which is supported by servlet 3.0
Summary: Fail to access the resources such as jsp files from a jar file which is suppo...
Status: RESOLVED FIXED
Alias: None
Product: Tomcat 7
Classification: Unclassified
Component: Servlet & JSP API (show other bugs)
Version: trunk
Hardware: PC Windows XP
: P2 normal (vote)
Target Milestone: ---
Assignee: Tomcat Developers Mailing List
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2010-08-06 21:52 UTC by Wang Guangzhe
Modified: 2010-08-23 15:40 UTC (History)
0 users



Attachments
the war file with more than one jar files (80.30 KB, application/octet-stream)
2010-08-09 21:21 UTC, Wang Guangzhe
Details
the war file with only one jar file (20.07 KB, application/octet-stream)
2010-08-09 21:22 UTC, Wang Guangzhe
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Wang Guangzhe 2010-08-06 21:52:37 UTC
I put a jsp file in a jar file and test whether tomcat 7 supports it by viewing it from the browser and failed.
Comment 1 Konstantin Kolinko 2010-08-09 06:01:22 UTC
Probably your jar does not have a META-INF/web-fragment.xml file and thus is skipped.

You can look at jar files in webapp-3.0-fragments test webapp for a working example,
http://svn.apache.org/repos/asf/tomcat/trunk/test/webapp-3.0-fragments/WEB-INF/lib/
Comment 2 Larry Isaacs 2010-08-09 09:48:40 UTC
Hi Konstantin,

During my work on the Tomcat support in Eclipse Web Tools, the only requirement I found in the Servlet 3.0 spec for static resources in a jar was that they be found under "META-INF/resources" in the jar.  I didn't see any requirement that the jar be a web-fragment.

Wang,

Since this behavior is only defined for Servlet 3.0 web applications, if your project has a web.xml, make sure it is a Servlet 3.0 web.xml in addition to making sure the JSP is in the "META-INF/resources" folder of the jar.  A quick test shows this working for me for Tomcat 7.0.0 and 7.0.2 (currently under vote).

Cheers,
Larry
Comment 3 Wang Guangzhe 2010-08-09 21:18:41 UTC
(In reply to comment #2)
> Hi Konstantin,
> 
> During my work on the Tomcat support in Eclipse Web Tools, the only requirement
> I found in the Servlet 3.0 spec for static resources in a jar was that they be
> found under "META-INF/resources" in the jar.  I didn't see any requirement that
> the jar be a web-fragment.
> 
> Wang,
> 
> Since this behavior is only defined for Servlet 3.0 web applications, if your
> project has a web.xml, make sure it is a Servlet 3.0 web.xml in addition to
> making sure the JSP is in the "META-INF/resources" folder of the jar.  A quick
> test shows this working for me for Tomcat 7.0.0 and 7.0.2 (currently under
> vote).
> 
> Cheers,
> Larry

Hi, Larry

I also test an very simple case where there are only one jar file in the lib, it runs well. But when there are more than one jar files, it fails.

I attach the two war files and please help to verify.

Thanks!
Comment 4 Wang Guangzhe 2010-08-09 21:21:21 UTC
Created attachment 25867 [details]
the war file with more than one jar files
Comment 5 Wang Guangzhe 2010-08-09 21:22:19 UTC
Created attachment 25868 [details]
the war file with only one jar file
Comment 6 Larry Isaacs 2010-08-10 11:13:54 UTC
I believe the problem is in step 8 in the ContextConfig.webConfig() method.  Based on my read of the Servlet 3.0 spec (section 4.6 only says JAR and states order is undefined), the "processResourceJARs(orderedFragments)" should be "processResourceJARs(fragments)" instead.

Wang,

Because your web.xml specifies an <absolute-ordering>, jars which do not have a web-fragment.xml will not appear in the orderedFragments list and won't be scanned for static resources.  Adding a web-fragment.xml as Konstatin suggests would work around the problem for now, assuming the <absolute-ordering> can't be removed.

Larry
Comment 7 Mark Thomas 2010-08-23 15:40:12 UTC
That's what I get for trying to force an order to get consistent behaviour.

Larry's analysis is spot on.

I have fixed this in trunk and it will be included in 7.0.3 onwards. The order enforced now is: ordered JARs in fragment order then all remaining JARs in random order.