cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Joerg Henne <j.he...@levigo.de>
Subject [Fwd: [C2] Bug in XSLTProcessorImpl?]
Date Tue, 18 Sep 2001 14:33:30 GMT
[This is a re-post of a pending patch. 
Dims: the attached patch contains the version of the patch modified to your
wishes.]

Joerg Henne wrote:
> 
> Hi,
> 
> there seems to be a problem with the XSLTProcessorImpl which surfaces under
> very special circumstances. If an entity catalog is used from within an
> included xslt stylesteet, the following situation ensues:
> 
> - the XSLTProcessorImpl's resolve method resolves the included stylesheet's
> name against a base like "file:/path/to/including/stylesheet".
> - due to the way it works, it prepends a leading slash after the colon leading
> to a result like "file://path/to/included/stylesheet". This uri is broken,
> however, cocoon's SourceResolver is still able to use it.
> - the entity catalog used within the included stylesteet is looked up based on
> the above uri. This eventually fails as xerces' DefaultReaderFactory creates a
> URL from the uri and tries a URL.openStream() leading to a host lookup for
> "path" and further mayhem.
> 
> This problem seems to be specific to the unix platform (tested under
> Linux/JDK1.3) due to the fact that URLs of the style "file:/x:/path/..." work
> just like those without the first slash.
> The attached patch fixes the problem. I've tested the patched code under
> Windows/JDK1.3 and it seems to work fine there as well. However, this patch
> should still be reviewed carefully.
> 
> Joerg Henne
> 
>   ------------------------------------------------------------------------------
>                  Name: patch.diff
>    patch.diff    Type: Plain Text (text/plain)
>              Encoding: 7bit
> 
>    Part 1.3Type: Plain Text (text/plain)
Mime
View raw message