DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT <http://nagoya.apache.org/bugzilla/show_bug.cgi?id=20904>. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE.
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=20904 XSLT processor setSystemID is not called, therefore base-uri empty Summary: XSLT processor setSystemID is not called, therefore base-uri empty Product: Cocoon 2 Version: 2.0.4 Platform: PC OS/Version: Windows NT/2K Status: NEW Severity: Normal Priority: Other Component: core AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] I have tried to use jd.xslt as the xslt processor for Cocoon. Works great in general except some problems with relative URI's. I mailed with the author of jd.xlst and he provided me with the output below. Cocoon uses the javax.xml.transform.sax.TemplatesHandler interface to create Transformer-objects. Therefore the stylesheet document is given to the XSLT processor as a SAX event stream. (see org.apache.cocoon.components.xslt.XSLTProcessorImpl) The TemplatesHandler interface has a method setSystemId() to provide the system id of the stylesheet before the SAX event stream is piped into the TemplatesHandler. This method is not called by Cocoon which actually breaks the contract specified by TemplatesHandler. In that case jd.xslt uses just the empty systemId "". Xalan also uses the SAX locator information in case the system id is not provided and therefore it suceeds. In Cocoon milestone 2.1m2 the method TemplatesHandler.setSystemId is called by org.apache.cocoon.components.xslt.XSLTProcessorImpl (and therfore jd.xslt should succeed), but XSLTProcessorImpl is deprecated in 2.1m2 and I don't know what is now the preferred way to invoke a Trax-XSLT processor. Short message: Cocoon uses Trax in a non-conformant way and therefore jd.xslt fails. It seems a bug to me in 2.0.4.
