Mailing-List: contact dev-help@cocoon.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@cocoon.apache.org
Received-SPF: pass (asf.osuosl.org: domain of ap-cocoon-dev@m.gmane.org
 designates 80.91.229.2 as permitted sender)
To: dev@cocoon.apache.org
From: Hussayn dabbous <hussayn.dabbous@saxess.de>
Subject: Re: patch for an entityResolver problem in xsl stylesheets ...
Date: Sat, 02 Sep 2006 00:45:21 +0200
Lines: 89
Message-ID: <edad61$kg4$1@sea.gmane.org>
References: 
 <FDD5D99066749040AF9098A720E9897701CA18A3@CIWMEXZSA0E.ex.ordersx.org>
 <44F89C30.4010008@reverycodes.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US;
 rv:1.7.13) Gecko/20060414
In-Reply-To: <44F89C30.4010008@reverycodes.com>
Sender: news <news@sea.gmane.org>

Vadim Gritsenko wrote:
> Nathaniel Alfred wrote:
> 
>> Hi Hussayn,
>>
>> thanks for sharing your patch.
>> I'll have a look at it.
> 
> 
> IIUC, the problem with this patch is that it drops usage of Source and 
> replaces it with jaxp API. Which means, if bug description is correct, 
> that Source still is not using entity resolver as one would expect, and 
> any other XML file (beside XSLT) won't be able to use entity resolver as 
> well.

How does this match with the observation that XML-file parsing does use
EntityResolver correctly except(!) in the context of XSLT stylesheet includes/imports/document()
calls ?

> Preferred bug fix IMHO should fix the original issue - source not using 
> entity resolver - instead of bypassing it.

The original TraxProcessor creates instances of
javax.xml.transform.stream.StreamSource whenever an import/include or
document shall be performed from within XSLT. Unfortunately StreamSource instances
only accept java.io.Reader instances as reader. But IMHO we need to use an
org.xml.sax.XMLReader in order to enable EntityResolving.

Since java.util.Reader is incompatible with org.xml.sax.XMLReader
i essentially replaced the StreamSource by a SAXSource. Do yu think, this
choice is wrong and there is a better alternative around ?

hussayn

> 
> Vadim
> 
>> Cheers, Alfred.
>>
>> -----Original Message-----
>> From: news [mailto:news@sea.gmane.org] On Behalf Of Hussayn dabbous
>> Sent: Mittwoch, 30. August 2006 22:48
>> To: dev@cocoon.apache.org
>> Subject: patch for an entityResolver problem in xsl stylesheets ...
>>
>> Hi;
>>
>> I tried to use external entities like &uuml; etc. in xsl stylesheets.
>> For this purpose in first place i added a DOCTYPE definition on top of
>> my stylesheet, i.e.:
>>
>>
>> <?xml version="1.0"?>
>> <!DOCTYPE mydoc [
>>    <!ENTITY % ISOlat1 PUBLIC "ISO 8879:1986//ENTITIES Added Latin
>> 1//EN//XML" "ISOlat1.pen"> %ISOlat1;
>> ]><xsl:stylesheet version="1.0">
>> ...
>>
>> I assumed, the default entity resolver would resolve the ISOlat1.pen,
>> but it did not!
>> I tracked this down and found, that entity resolution only works
>> correctly when i
>> set the SYSTEM identifier to the absolute location of the external
>> entity file. I did
>> not like this "hack", hence i tracked the problem further down and
>> eventually found
>> one location in TraxProcessor.java which apparently needs a modification
>> in order to inject
>> the correct EntityResolver to work as expected.
>>
>> I finally created a patch, which adds Entity resolving within XSLT
>> processing wherever
>> a document(), import or include is performed. i did not check whether
>> this patch works
>> recursively (follows an import within an imported xsl), but it looks
>> like it would do ...
>>
>> The patch has been created against cocoon/branches/BRANCH_2_1_X
>> It works for me. Hopefully it is usefull for others and does not break
>> code at other
>> places. If anyone would like to review the patch and give some feedback,
>> That would be great ;-)
>>
>> best regards,
>> Hussayn
> 
> 
>