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=13850>. 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=13850 xsltc type match problem with docbook test in xsltmark Summary: xsltc type match problem with docbook test in xsltmark Product: XalanJ2 Version: CurrentCVS Platform: Other OS/Version: Other Status: NEW Severity: Critical Priority: Other Component: org.apache.xalan.xsltc AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] We run a docbook test as part of a customized XSLTCMARK performance test suite. I caught a regression on the docbook testcase in the xsltmark performance benchmark with XSLTC. Santi thought it had something to do with the Xalan/XSLTC integration extension work Morris Kwan recently did. Here is the error message: docbook: docbook.xsl ERROR: 'Cannot convert argument/return type in call to method 'org.apache.xalan.lib.ExsltSets.leading(reference, reference)'' javax.xml.transform.TransformerConfigurationException: Could not compile stylesheet at org.apache.xalan.xsltc.trax.TransformerFactoryImpl.newTemplates(TransformerFactoryImpl.java:662) at com.datapower.xsltmark.XSLTCTRAXDriver.loadStylesheet(XSLTCTRAXDriver.java:77) at com.datapower.xsltmark.XSLTMark.runBenchmark(XSLTMark.java:72) at com.datapower.xsltmark.XSLTMark.main(XSLTMark.java:509) I attached the docbook stylesheet where the problem seems to be happening and here is a snippet that might help you understand it. <xsl:template name="unwrap.p"> <xsl:param name="p"/> <xsl:choose> <xsl:when test="function-available('exsl:node-set') and function-available('set:leading') and function-available('set:trailing')"> <xsl:apply-templates select="exsl:node-set($p)" mode="unwrap.p"/> </xsl:when> <xsl:otherwise> <xsl:copy-of select="$p"/> </xsl:otherwise> </xsl:choose> </xsl:template> Here's another snippet from the same xsl file (html-rtf.xsl) <!-- This template should never get called if these functions aren't available --> <!-- but this test is still necessary so that processors don't choke on the --> <!-- function calls if they don't support the set: functions --> <xsl:if test="function-available('set:leading') and function-available('set:trailing')"> <xsl:choose> <xsl:when test="$blocks"> <xsl:variable name="leading" select="set:leading($nodes,$blocks)"/> <xsl:variable name="trailing" select="set:trailing ($nodes,$blocks)"/> Morris Kwan responded: I can reproduce the problem. I would not call it a regression because the underlying problem exists before the extension integration. It did not show up because previously function-available("set:leading") returned false and the block inside <xsl:if> did not get evaluated. With the extension changes, function-available() returns true. Now more code runs through the compiler and you have a better chance to uncover a problem which was not caught before. The problem has something to do with the type of a <xsl:param>. In the instruction set:leading($nodes,$blocks), both $nodes and $blocks are parameters. The default type of a parameter is Reference. However, the set:leading function expects the two arguments to be of type nodeset. The types do not match and the exception is thrown. I also notice other problems when using parameters in function arguments. I am going to find a solution for this problem. I will let Santiago review the solution before putting it in.
