Bug 48689 - Jar abstraction for Jasper
Summary: Jar abstraction for Jasper
Status: RESOLVED FIXED
Alias: None
Product: Tomcat 7
Classification: Unclassified
Component: Jasper (show other bugs)
Version: trunk
Hardware: PC Linux
: P2 enhancement (vote)
Target Milestone: ---
Assignee: Tomcat Developers Mailing List
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2010-02-05 12:30 UTC by Jarek Gawor
Modified: 2010-04-25 08:57 UTC (History)
0 users



Attachments
Proposed patch for this issue. (34.80 KB, patch)
2010-02-05 12:38 UTC, Jarek Gawor
Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Jarek Gawor 2010-02-05 12:30:40 UTC
Jasper can load TLD files through the ServletContext or from a Jar file. To load TLDs from Jar file, an URL to a Jar file must be passed. However, in some environments (e.g. in OSGi) it might not be easy to provide an URL to a jar file. It would be nice to abstract the way Jasper is looking up the embedded TLDs so that different ways of looking up TLDs within Jar files or Bundles or whatever could be used.
Comment 1 Jarek Gawor 2010-02-05 12:38:53 UTC
Created attachment 24933 [details]
Proposed patch for this issue.

Proposed patch for this issue is now attached. The patch introduces JarResource interface through which most of the embedded TLD lookup is done. In most places the code uses JarResource.getEntry() to get an URL to a specific entry within the JarResource. In one or two places JarResource.getJarFile() is used but really JarResource.getEntry() should be preferred.
Comment 2 Mark Thomas 2010-02-06 05:53:31 UTC
Tomcat 7 already includes a number of features added specifically to support TLD scanning in OSGi environments. Can you elaborate as to what you can't currently do with Tomcat 7?

Also, could you provide an example of situations when a URL can't be provided?
Comment 3 Jarek Gawor 2010-02-06 10:01:14 UTC
First, can you quickly describe or point me to the features that were added to support TLD scanning in OSGi env. in case I missed them?

We have a custom implementation of TldLocationsCache.java. If the TLD is within the application bundle (accessible via ServletContext or within a jar file in a bundle) everything works fine. But in some cases we want to return a TLD that is located in another bundle. So all we have is a URL to the TLD. For example, something like bundle://123:0/META-INF/foo.tld. And in this case there is no "jar url" I can pass/return to Jasper.
Comment 4 Mark Thomas 2010-02-06 12:13:37 UTC
It was bug47834 and mainly r814617 and r817685.

Bundles (as long as they are on the class path) are handled if org.apache.jasper.compiler.TldLocationsCache.SCAN_ALL_FILES is set as any file on the class path is checked to see if it is in JAR format and if it is, it is scanned.

Exploded bundles (again as long as they are on the class path) are handled if org.apache.jasper.compiler.TldLocationsCache.SCAN_ALL_DIRS is set and any directory on the class path is checked to see it it is an exploded JAR/bundle. If it is it is scanned.

As an aside, the TLD scanning is likely to see another refactoring once the Servlet 3.0 work is complete to take advantage of some of the new features to simplify the code.
Comment 5 Jarek Gawor 2010-02-08 08:01:38 UTC
Thanks for the pointers. I am aware of that code but it doesn't really help or address the problem described in this bug. Jasper shouldn't require (as it doesn't really need) a jar url to be passed from TldLocationsCache just to parse the TLD or tag files within it. The problem is not with TLD scanning itself but what TldLocationsCache.getLocation() method forces me to return and rest of the Jasper code that uses the location information to do its stuff.
Comment 6 Mark Thomas 2010-04-25 08:57:13 UTC
Thanks for the patch. It has been applied to 7.0.x and will be included in 7.0.0 onwards.