cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Jorg Heymans (JIRA)" <>
Subject [jira] Commented: (COCOON-2022) broken URI handling in ZipSource
Date Sat, 17 Mar 2007 11:18:09 GMT


Jorg Heymans commented on COCOON-2022:

digging a bit deeper into this...

The file:/ url is constructed in o.a.excalibur.source.impl.FileSource, line 100 :

I suspect that if you put a breakpoint there you will get the correct URL file://

According to google this is sort of accepted 'broken' behaviour on jdk 1.3, on 1.4 and upwards
one should use something like file.toURI().toASCIIString()

See e.g.
 xxxxx@xxxxx , 2003-10-01 07:01:33 : 
OK, I'll try to go through the listed conversions as best I know:

new URI(String) - fine
URI.toASCIIString() - OK, but toExternalForm = toString is fine
File.toURI() - fine
new File(URI) - fine
URLMapper.findFileObjects(URL) - fine
FileObject.getURL() - works, but URLMapper.findURL(FileObject,int) is
probably more useful
URI.toURL() - fine
new URI(URL.toExternalForm()) - fine

You forgot:

new File(new URI(URL.toExternalForm())

What is *not* safe:

File.toURL() - does not work correctly
new File(URL.getPath().replace('/', File.separatorChar)) - does not work

See also: 
it's worse than you thought. file.toURL().toExternalForm() doesn't always work. The URL object
that toURL() returns does not correctly implement the URL specification for many characters
likely to occur in file names, including the simple space (0x20). This can trip up relative
URL resolution too.
In Java 1.4 and later you should use file.toURI().toASCIIString() instead. In Java 1.3 and
earlier, you'll need to build the URL from the file name yourself because Java's implementation
is just too broken.

To summarize : i think the behaviour is buggy but seemingly accepted to be broken and thus
in a wierd kind of way you could say it is 'correct' within the scope of this test. 

How about we do:

String brokenURI = "file:/";
if (! (uri.equals(source.getURI() || brokenUri.equals(source.getURI()) ){
  fail("expected either " + uri + " or " + brokenURI + " but resolved URI was " + source.getURI());

> broken URI handling in ZipSource
> --------------------------------
>                 Key: COCOON-2022
>                 URL:
>             Project: Cocoon
>          Issue Type: Bug
>          Components: * Cocoon Core
>    Affects Versions: 2.1.10
>            Reporter: Jörg Heinicke
>         Assigned To: Jörg Heinicke
>            Priority: Minor
> On behalf of Leonid Geller:
> 1. Bug in org.apache.cocoon.components.source.impl.ZipSourceFactory, on this line:
>         // Get protocol. Protocol is configurable via cocoon.xconf
>         final String protocol = location.substring(0, protocolEnd - 1);
> Obviously it should be location.substring(0, protocolEnd). This is what causes zip to
be truncated to "zi".
> 2. When using a SYSTEM identifier with relative DTD path, the XML parser will look for
the file relative to the URI of the zipped source,!/source.xml which is obviously
going to fail.
> Here, the solution is to have the source implementation class (in this case org.apache.cocoon.components.source.impl.ZipSource)
to change getURI method to return source.xml based on location, w/o the zip protocol.
Current implementation:
> 	return this.protocol + this.archive.getURI() + "!/" + this.filePath;
> is not going to work. Something like this will:
>     	int iZipIdx = this.archive.getURI().lastIndexOf("/");
> 	if (iZipIdx < 0) iZipIdx = 0;
>     	return this.archive.getURI().substring(0,iZipIdx)+"/"+ this.filePath;

This message is automatically generated by JIRA.
You can reply to this email to add a comment to the issue online.

View raw message