[jira] [Comment Edited] (FOP-2861) Allow resource loading from jar: URI

classic Classic list List threaded Threaded
1 message Options
Reply | Threaded
Open this post in threaded view
|

[jira] [Comment Edited] (FOP-2861) Allow resource loading from jar: URI

JIRA jira@apache.org

    [ https://issues.apache.org/jira/browse/FOP-2861?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16826940#comment-16826940 ]

Ole Sandum edited comment on FOP-2861 at 4/26/19 1:04 PM:
----------------------------------------------------------

I don't think so. I tried passing in a custom ResourceResover to apply the work-around, but it doesn't make its' way into InternalResourceResolver, so this still happens:

{{Caused by: java.lang.IllegalArgumentException: URI is not absolute}}
 {{  at java.net.URI.toURL(URI.java:1088)}}
 {{  at org.apache.fop.apps.io.ResourceResolverFactory$NormalResourceResolver.getResource(ResourceResolverFactory.java:224)}}
 {{  at org.apache.fop.apps.io.ResourceResolverFactory$TempAwareResourceResolver.getResource(ResourceResolverFactory.java:152)}}
 {{  at org.apache.fop.apps.io.ResourceResolverFactory$DefaultResourceResolver.getResource(ResourceResolverFactory.java:121)}}
 {{  at org.apache.fop.apps.io.InternalResourceResolver.getResource(InternalResourceResolver.java:92)}}
 {{  at org.apache.fop.fonts.truetype.OFFontLoader.read(OFFontLoader.java:111)}}

The "URI is not absolute" is the result of the relative font path not being resolved correctly against the jar:file:... base URI as mentioned above.

I have not been able to break into FopFactoryBuilder enough to inject a custom ResourceResolver here.


was (Author: osandum):
I don't think so. I tried passing in a custom ResourceResover to apply the work-around, but it doesn't make its' way into InternalResourceResolver, so this still happens:

{{Caused by: java.lang.IllegalArgumentException: URI is not absolute}}
{{  at java.net.URI.toURL(URI.java:1088)}}
{{  at org.apache.fop.apps.io.ResourceResolverFactory$NormalResourceResolver.getResource(ResourceResolverFactory.java:224)}}
{{  at org.apache.fop.apps.io.ResourceResolverFactory$TempAwareResourceResolver.getResource(ResourceResolverFactory.java:152)}}
{{  at org.apache.fop.apps.io.ResourceResolverFactory$DefaultResourceResolver.getResource(ResourceResolverFactory.java:121)}}
{{  at org.apache.fop.apps.io.InternalResourceResolver.getResource(InternalResourceResolver.java:92)}}
{{  at org.apache.fop.fonts.truetype.OFFontLoader.read(OFFontLoader.java:111)}}

I have not been able to break into FopFactoryBuilder enough to inject a custom ResourceResolver here.

> Allow resource loading from jar: URI
> ------------------------------------
>
>                 Key: FOP-2861
>                 URL: https://issues.apache.org/jira/browse/FOP-2861
>             Project: FOP
>          Issue Type: Improvement
>    Affects Versions: 2.0, 2.1, 2.2, 2.3
>            Reporter: Ole Sandum
>            Priority: Major
>         Attachments: uri_resolve.diff
>
>
> We would like to load our FOP config.xml along with related fonts and hyphenation files using  the common classloader URL, e.g.:
> {{  URL configXml = getClass().getResource("config.xml");}}
> {{  FopConfParser confParser = }}
> {{      new FopConfParser(configXml.openStream(), configXml.toURI());}}
> This makes for easy deployment, and works nicely as long as classes and resources are loaded from separate files, i.e. from file:/some/path/config.xml URIs. However, it fails when classes and resources are packaged and loaded directly from a jar, i.e. from jar:file:/some/archive.jar!/path/config.xml URIs, as is the case when deploying with JWS or running an all-in-one executable jar, as it will fail to properly resolve the related font and hyphenation file URIs. 
> See [https://github.com/osandum/fop-test.git] for a test to illustrate.
> This is a consequence of a long standing issue (reported in [https://bugs.openjdk.java.net/browse/JDK-8020755)] that URI.resolve(childUri) doesn't work as expected on jar:file: URIs.
> In this case, it can be easily remedied by a work-around to the call in InternalResourceResolver.resolveFromBase(URI uri). Patch attached.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)