cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jörg Heinicke (JIRA) <>
Subject [jira] Commented: (COCOON-2022) broken URI handling in ZipSource
Date Thu, 15 Mar 2007 22:29:09 GMT


Jörg Heinicke commented on COCOON-2022:

Ok, can you debug it? I especially wonder why it ends in "file:/" as the debug output
added by Jorg clearly says:

[DEBUG] Resolving 'file://' with base 'null' in context ...
[DEBUG] Resolved to systemID : file://
[DEBUG] Creating source object for file://

As the "inner" uri "file://" is resolved on its own and into a different Source object
the actual error is probably not even in ZipSource but somewhere else. The failing check on
ZipSource.getURI() only calls getURI() on the inner Source object. This inner Source object
is not manipulated in any way. So maybe also the test

    public void testURIHandling() throws Exception {
        String uri = "file://";
        Source source;
        SourceResolver resolver = null;
        try {
            resolver = (SourceResolver) getManager().lookup(SourceResolver.ROLE);
            source = resolver.resolveURI(uri);
        } catch (ServiceException se) {
            throw new SourceException("SourceResolver is not available.", se);
        } finally {
        assertEquals("Uri is wrong.", uri, source.getURI());

would fail for you?

> 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