Bug 40288

(In reply to comment #0)
> A file:// url in the <base> element in fopconfig.xml must end with a slash on 
> Linux. If it does not, images (specified by "url(foo)" where foo is a relative 
> file name) won't be found and will thus not be added to the PDF. FOP should 
> probably either accept both ways to specify the url or display an ERROR that 
> refers to this setting. This would make it much easier to debug this problem.

Well, this is the normal behavior of URLs (and more generally URIs). When
resolving a relative reference against a base URI, all the characters of the
base URI which are to the right of the rightmost slash are removed, and replaced
by the relative path:
file://path/to/images + myImage.png -> file://path/to/myImage.png
file://path/to/images/ + myImage.png -> file://path/to/images/myImage.png
So the ending slash is important!

The best Fop can do IMO is display the full resolved URI in the error message,
so that the user immediately sees that there is something wrong with URI resolution.

Hey, I didn't want to change the severity of this bug! Sorry :-\

Displaying the full URL in the error message sounds like a good solution to 
me. 

This bug should be fixed/addressed by [PATCH]
http://issues.apache.org/bugzilla/show_bug.cgi?id=41514

The full URL isn't yet displayed when the resolution of a resource failed.

Created attachment 19603 [details]
logs full url - not just relative part if there is a failed resolution

Comment on attachment 19603 [details]
logs full url - not just relative part if there is a failed resolution

Index: C:/workspace/fop/src/java/org/apache/fop/apps/FOURIResolver.java
===================================================================
--- C:/workspace/fop/src/java/org/apache/fop/apps/FOURIResolver.java   
(revision 507572)
+++ C:/workspace/fop/src/java/org/apache/fop/apps/FOURIResolver.java   
(working copy)
@@ -155,7 +155,7 @@
	     //Note: This is on "debug" level since the caller is supposed to
handle this
	     log.debug("File not found: " + effURL);
	 } catch (java.io.IOException ioe) {
-	     log.error("Error with opening URL '" + href + "': " +
ioe.getMessage());
+	     log.error("Error with opening URL '" + effURL + "': " +
ioe.getMessage());
	 }
	 return null;
     }
@@ -202,6 +202,9 @@
      * @returns the base URL as java.net.URL
      */
     private URL toBaseURL(String baseURL) {
+	 if (!baseURL.endsWith("/")) {
+	     log.warn("Base url does not end with a '/'.  This could cause
resolution problems");
+	 }
	 try {
	     return new URL(baseURL == null 
			     ? new java.io.File("").toURL().toExternalForm()

Created attachment 19604 [details]
logs full url - not just relative part if there is a failed resolution

not warns about base urls not ending with '/' chars

Not sure I like the warning. There is no requirement for a base URL to end with a /.

Created attachment 19607 [details]
logs full url - not just relative part if there is a failed resolution

Ammends base url as necessary with trailing '/'.  I can't think of any
reason/instance when you would want to lose the end part of your base url
because you neglected to append a trailing slash.

(In reply to comment #10)
> Created an attachment (id=19607) [edit]
> logs full url - not just relative part if there is a failed resolution
> 
> Ammends base url as necessary with trailing '/'.  I can't think of any
> reason/instance when you would want to lose the end part of your base url
> because you neglected to append a trailing slash.

Patch applied with some modifications. Thanks Adrian!

Please leave bugs open when submitting patches. We will close them when applying
the patches.
I re-open this bug because the problem isn't entirely solved yet. The full URL
doesn't appear in strict user config validation mode. Also, when I specify a
wrong base-font URL (pointing to a non-existing directory), this throws a
catched FileNotFoundException (FOURIResolver.java, l.159), and null is returned.
Thus FontSetup displays an error message (or throws a ConfigurationException)
with the relative URL (FontSetup.java, l.291).

Vincent

Isn't a full URL, that is a URL pointing to a file resource a legal base URL
which will now fail? For example if I set the base URL to the file I am
processing, lets say 'file:///home/mm/test.xml' the previous version would
accept that and resolve references relative to that while now we are appending a
/ and it will fail.

(In reply to comment #12)
> Isn't a full URL, that is a URL pointing to a file resource a legal base URL
> which will now fail? For example if I set the base URL to the file I am
> processing, lets say 'file:///home/mm/test.xml' the previous version would
> accept that and resolve references relative to that while now we are appending a
> / and it will fail.

Indeed, and I was also concerned by that at the beginning. But that code is used
only to handle the <base> and <font-base> elements in the user config file,
where it would be really unusual to see URLs pointing to files instead of
directories. And anyway such cases would happen with power users having a good
understanding of relative URL resolution. If they have the full URL in the error
message, they will understand that they have to remove the last part of it to
make the thing work. So this change looks safe to me.
Now if a majority of the developers have concerns about that I can revert it. We
can also move that piece of code to the place where base/font-base are retrieved.

WDYT?
Vincent

Admittedly I haven't looked at the code in detail but wouldn't the same logic
apply when setting the base URL programatically. I can easily envisage an
environment where the XML/FO to process comes from some source whose location
varies and the programmer dynamically sets the base URL to the input file in
question. It boils down to that a base URL is something different than a base
directory or base file system path.

I would prefer to strengthen our documentation, add appropriate comments to our
sample config file and may be add a hint as part of the error message compared
to making a FOP base URL meaning something different than in the rest of the URL
resolution world.

But in the end its really a very minor issue and I be happy to go with whatever
the FOP committer majority prefers.

resetting P2 open bugs to P3 pending further review