DO NOT REPLY [Bug 17825] New: - XSLTC assumes context-relative paths, not directory-relative

[bu...@apache.org]

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: cocoon-dev@xml.apache.org
        ReportedBy: jefft@apache.org


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