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=17825>. 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=17825 XSLTC assumes context-relative paths, not directory-relative Summary: XSLTC assumes context-relative paths, not directory- relative Product: Cocoon 2 Version: Current CVS Platform: Other OS/Version: Other Status: NEW Severity: Blocker Priority: Other Component: sitemap components AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] Say I have a stylesheet in a subdirectory, stylesheets/site2xhtml.xsl, containing: <xsl:param name="config-file" select="'../skinconf.xml'"/> This is intended to reference a file 'skinconf.xml' in the context root. Works fine with vanilla Xalan. When I use XSLTC, the the '../skinconf.xml' isn't resolved properly. If I change it to 'skinconf.xml' it works, from which I infer that XSLTC thinks URLs should be resolved relative to the context, not the directory the stylesheet is in. Here is the stacktrace: org.apache.xalan.xsltc.TransletException: java.io.FileNotFoundException: ../skinconf.xml at org.apache.xalan.xsltc.dom.LoadDocument.document(LoadDocument.java:137) at org.apache.xalan.xsltc.dom.LoadDocument.document(LoadDocument.java:216) at site2xhtml.topLevel() at site2xhtml.transform() at org.apache.xalan.xsltc.runtime.AbstractTranslet.transform(AbstractTranslet.java:497) at org.apache.xalan.xsltc.trax.TransformerImpl.transform(TransformerImpl.java:635) at org.apache.xalan.xsltc.trax.TransformerImpl.transform(TransformerImpl.java:256) at org.apache.xalan.xsltc.trax.TransformerHandlerImpl.endDocument(TransformerHandlerImpl.java:240) at org.apache.cocoon.xml.AbstractXMLPipe.endDocument(AbstractXMLPipe.java:91) at org.apache.cocoon.transformation.TraxTransformer.endDocument(TraxTransformer.java:498) at org.apache.xerces.parsers.AbstractSAXParser.endDocument(AbstractSAXParser.java:741) at org.apache.xerces.impl.XMLNamespaceBinder.endDocument(XMLNamespaceBinder.java:705) at org.apache.xerces.impl.dtd.XMLDTDValidator.endDocument(XMLDTDValidator.java:918) at org.apache.xerces.impl.XMLDocumentScannerImpl.endEntity(XMLDocumentScannerImpl.java:451) at org.apache.xerces.impl.XMLEntityManager.endEntity(XMLEntityManager.java:1246) at org.apache.xerces.impl.XMLEntityManager$EntityScanner.load(XMLEntityManager.java:3283) at org.apache.xerces.impl.XMLEntityManager$EntityScanner.skipSpaces(XMLEntityManager.java:2953) at org.apache.xerces.impl.XMLDocumentScannerImpl$TrailingMiscDispatcher.dispatch(XMLDocumentScannerImpl.java:1017) at org.apache.xerces.impl.XMLDocumentFragmentScannerImpl.scanDocument(XMLDocumentFragmentScannerImpl.java:329) at org.apache.xerces.parsers.DTDConfiguration.parse(DTDConfiguration.java:525) at org.apache.xerces.parsers.DTDConfiguration.parse(DTDConfiguration.java:581) at org.apache.xerces.parsers.XMLParser.parse(XMLParser.java:152) at org.apache.xerces.parsers.AbstractSAXParser.parse(AbstractSAXParser.java:1175) at org.apache.excalibur.xml.impl.JaxpParser.parse(JaxpParser.java:302) at org.apache.excalibur.xmlizer.DefaultXMLizer.toSAX(DefaultXMLizer.java:161) I'm not sure if this is an XSLTC bug (isn't fixed in latest CVS anyway), or if Cocoon isn't passing XSLTC enough context (like the XSLT's real path). Attached is a sub-sitemap demonstrating the problem, which you should be able to drop into build/webapp/, and access by requesting http://localhost:8080/cocoon/xsltcbug/ --Jeff
