Bug 48737 - JspCompilationContext assumes that tagfile with a path starting with META-INF are in jars without checking
Summary: JspCompilationContext assumes that tagfile with a path starting with META-INF...
Status: RESOLVED FIXED
Alias: None
Product: Tomcat 6
Classification: Unclassified
Component: Jasper (show other bugs)
Version: 6.0.24
Hardware: PC Linux
: P2 normal (vote)
Target Milestone: default
Assignee: Tomcat Developers Mailing List
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2010-02-13 18:19 UTC by Fabrizio Giustina
Modified: 2010-05-14 15:53 UTC (History)
0 users



Attachments
patch to JspCompilationContext (764 bytes, patch)
2010-02-13 18:19 UTC, Fabrizio Giustina
Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Fabrizio Giustina 2010-02-13 18:19:03 UTC
Created attachment 24978 [details]
patch to JspCompilationContext

This is a pretty special case, since tagfiles in META-INF are usually in jar files...
but when using a custom dircontext implementation (usually during development in order to load files from the filesystem without building a full jar) it may happen that the path given to jasper starts with META-INF also if the file is not in a jar. This is what happens using the Eclipse WTP tomcat loader, which loads classes from the workspaces and tld/tagfiles from directories inside your projects.

Tagfiles contained in META-INF directories worked properly till tomcat 6.0.17, but the final fix for BUG 43741 broke it (I am still using 6.0.16 and not upgrading due to this problem).

Looking at JspCompilationContext.getResource() the patch to solve this problem would be very simple and "safe": if the path starts with META-INF and a jar file containing the tld doesn't exist the resulting URL is simply null.
Adding a check for the null jar and setting the URL to the "standard" path inside the context fixes the problem and everything starts working again (note that this doesn't break the previous fix and it can't cause any problem, since the result would have been null anyway).


A patch against trunk (2010-02-13) is attached, the following code should easily displays what the patch does: 

        URL result = null;
        if (res.startsWith("/META-INF/")) {
           // some lines to get the jar url
           // ...
           if (jarUrl != null) {
               result = new URL(jarUrl.toExternalForm() + res.substring(1));
           }
+          else {
+              // the path starts with /META-INF but the file is not in a jar
+              result = context.getResource(canonicalURI(res));
+          }
        }
Comment 1 Mark Thomas 2010-03-09 12:34:30 UTC
Thanks for the patch.

This has been fixed in trunk and proposed for 6.0.x
Comment 2 Fabrizio Giustina 2010-03-16 14:42:10 UTC
(In reply to comment #1)
> Thanks for the patch.
> 
> This has been fixed in trunk and proposed for 6.0.x

great! Can you tell if it has been included in 6.0.26? I couldn't find a good way to guess this from bugzilla...
Comment 3 Mark Thomas 2010-03-16 15:15:57 UTC
That would be what the 6.0.26 change log is for.
Comment 4 Fabrizio Giustina 2010-03-21 19:10:44 UTC
(In reply to comment #3)
> That would be what the 6.0.26 change log is for.

you are right, I'm too used with the "fixed versions" in jira...

so it's not in 6.0.26, any chance to see it in a 6.0.x release soon? Thanks
Comment 5 Mark Thomas 2010-05-14 15:53:09 UTC
Thanks again for the patch. This has been fixed in 6.0.x and will be included in 6.0.27 onwards.