You are viewing a plain text version of this content. The canonical link for it is here.
Posted to jetspeed-dev@portals.apache.org by Dave Carlson <dc...@ontogenics.com> on 2001/09/08 00:45:55 UTC
bug fix for SimpleTransform.java
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"
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.
This can be fixed by setting the systemId after constructing the Source with
the Reader. But, it's simpler to just create the Source from the URL of the
cached stylesheet. The global change above does this. Now, I can
successfully run with Saxon. (But note that you must use the most current
Saxon version, 6.4.3, do to a bug fix in Saxon.)
Can someone make this change in CVS?
Cheers,
Dave Carlson
---------------------------------------------------------------------
To unsubscribe, e-mail: jetspeed-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: jetspeed-dev-help@jakarta.apache.org
Re: bug fix for SimpleTransform.java
Posted by Dave Carlson <dc...@ontogenics.com>.
Thank you Santiago. I will update and test this change. I don't have access
to good multilingual content examples, so don't always pay enough attention to
coding practices for other encodings and use of Reader vs. URLs.
----- Original Message -----
From: "Santiago Gala" <sg...@hisitech.com>
> > 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: jetspeed-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: jetspeed-dev-help@jakarta.apache.org
Re: bug fix for SimpleTransform.java
Posted by Santiago Gala <sg...@hisitech.com>.
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: jetspeed-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: jetspeed-dev-help@jakarta.apache.org
Re: bug fix for SimpleTransform.java
Posted by Santiago Gala <sg...@hisitech.com>.
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.
Re: bug fix for SimpleTransform.java
Posted by Santiago Gala <sg...@hisitech.com>.
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() );
patching JetspeedXMLEntityResolver to setSystemID again on the resulting
InputSource ...
I will try this with saxon and report. What do you think?
Please remember me. I'm just too busy.
>
>This can be fixed by setting the systemId after constructing the Source with
>the Reader. But, it's simpler to just create the Source from the URL of the
>cached stylesheet. The global change above does this. Now, I can
>successfully run with Saxon. (But note that you must use the most current
>Saxon version, 6.4.3, do to a bug fix in Saxon.)
>
>Can someone make this change in CVS?
>
>Cheers,
> Dave Carlson
>
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: jetspeed-dev-unsubscribe@jakarta.apache.org
>For additional commands, e-mail: jetspeed-dev-help@jakarta.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: jetspeed-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: jetspeed-dev-help@jakarta.apache.org