Santiago Gala wrote:
> Santiago Gala wrote:
>
>> Dave Carlson wrote:
>>
>>> I need to use the Saxon XSLT processor with Jetspeed for other
>>> portlet content
>>> (and another application running in the same Tomcat instance).
>>> However, I was
>>> getting errors when I added saxon as the default XSLT processor. I
>>> tracked
>>> down a simple bug fix to SimpleTransform.java
>>>
>>> Short answer:
>>> Do a global replace of "getReader" and replace with "getURL"
>>>
>> It is not this simple. The whole purpose of having getReader() called
>> is to abstract Character encoding *and* cache location issues.
>> getURL() should be forbiden, as it exposes the internals on how the
>> cache works, and is bound to failure as the cache changes. Also, it
>> leads to funny character encoding issues.
>>
>>>
>>> When SimpleTransform fetches the stylesheets from the disk cache, it
>>> creates a
>>> SAX parser based on a Reader for the cached file. However, in
>>> Saxon, it
>>> requires setSystemId() to be called on the Source so that the parser
>>> can use
>>> the source's systemId to determine the base URI for resolving
>>> relative URLs.
>>>
>> I think a Entity Resolver can take care of this process. I'm not
>> completely sure how, though.
>>
>> I would like to help with a cleaner fix. I think we could call
>> setEntityResolver() on the InputSource with the true URL (not the one
>> in the cache), so that, in case there are relative URLs they can be
>> resolved.
>>
>> I imagine something like:
>>
>> is = new InputSource( cacheEnt.getReader() );
>> is.setSystemID( cacheEnt.getSourceURL() );
>
>
>
>>
>> is.setEntityResolver( new
>> org.apache.jetspeed.xml.JetspeedXMLEntityResolver() );
>
>
> Sorry, this should be applied to the XMLReader(s)
>
>>
>>
>> patching JetspeedXMLEntityResolver to setSystemID again on the
>> resulting InputSource ...
>>
>> I will try this with saxon and report. What do you think?
>
>
>
> I am testing it with saxon.jar instead of xalan in webapps/lib, and it
> seems to work all right. So, should I commit the changes for you to test?
>
> Auditing (with grep) for more InputSource occurrences, I found
> SAXPIFilter (only user in XMLPortlet). This should be possibly be
> cleaned out, to write a better XMLPortlet...
>
> I attach the diffs, waiting for committing them if there is no problem.
I have commited, since the changes seem to be good coding practice, and
I have seen no problems under either saxon or xalan. Please report if
you find problems related with XML parsing or XSLT transformations.
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]