Hi Leonid,
thanks for your detailed investigations. I added it to Jira [1] and
fixed part 1. Additionally to this issue with protocolEnd there was an
error in getURI() of ZipSource. Instead of
return this.protocol + this.archive.getURI() + "!/" + this.filePath;
it has to be
return this.protocol + ":" + this.archive.getURI() + "!/" +
this.filePath;
On 12.03.2007 15:52, Leonid Geller wrote:
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;
For your 2nd part I don't know if I can follow or agree. Let's assume
there is a file "zip:file://test.zip!/test.xml" (as in the test case).
In which way do you expect a relative path to be resolved? IMO
zip:file://test.zip is the context and must not be left. So with a
relative "test.dtd" it should be "zip:file://test.zip!/test.dtd". Even
an absolute path like "/test.dtd" should stay in the zip archive
context, while I'd assume a path with protocol to be resolved out of
this context.
Regards
Jörg
[1] https://issues.apache.org/jira/browse/COCOON-2022
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
