[
https://issues.apache.org/jira/browse/COCOON-2022?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12481847
]
Jorg Heymans commented on COCOON-2022:
--------------------------------------
digging a bit deeper into this...
The file:/test.zip url is constructed in o.a.excalibur.source.impl.FileSource,
line 100 : file.toURL().toExternalForm();
I suspect that if you put a breakpoint there you will get the correct URL
file://test.zip.
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. http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4924415
--------------
[EMAIL PROTECTED] , 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:
File.toURI().toURL()
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:
http://weblogs.java.net/blog/kohsuke/archive/2005/10/xml_processing.html
---------------------------
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:/test.zip";
....
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: https://issues.apache.org/jira/browse/COCOON-2022
> 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:
> http://marc.theaimsgroup.com/?t=117337275500004&r=1&w=4:
> 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,
> zip:archive.zip!/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 archive.zip 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.
