CODEWITHSUNDEEP
xmlxsltsaxonxslt-3.0
Vinit
Vinit

Reputation: 1825

xsl:sort inside for-each-group()

For some reason xsl:sort inside a for-each-group is throwing an exception since upgrading to Saxon 9.7.0.1

XML-

<table class="vv">
        <tr><td>woot1</td><td>woot2</td></tr>
        <tr><td>woot1</td><td>woot2</td></tr>
        <tr><td>woot1</td><td>woot2</td></tr>
        <tr><td>woot1</td><td>woot2</td></tr>
</table>

XSL-

<xsl:template match="/">
  <xsl:apply-templates/>
</xsl:template>

<xsl:template match="table[@class='vv']">
    <div class="row">
        <xsl:for-each-group select="tr" group-by="td[1]/text()">
            <xsl:sort/>
            test
        </xsl:for-each-group>
    </div>
</xsl:template>

Error-

enter image description here

Just want to verify if this is a bug in Saxon or something got changed with the way this used to work in XSLT 3.0

Upvotes: 3

Views: 854

Answers (2)

Caroline S
Caroline S

Reputation: 11

I don't think this is a real fix but, Mysteriously enough, you can add a <xsl:value-of select="current-grouping-key()"/> statement in the for-each-group body, and the exception goes away. It can be in a comment.

<xsl:template match="table[@class='vv']" mode="copy">
    <div class="row">
        <xsl:for-each-group select="tr" group-by="td[1]/text()">
            <xsl:sort/>
            <xsl:comment><xsl:value-of select="current-grouping-key()"/></xsl:comment>
           test 
        </xsl:for-each-group>
    </div>
</xsl:template>

Upvotes: 1

Michael Kay
Michael Kay

Reputation: 163595

An IncompatibleClassChangeError generally means that there's a class loaded by the JVM at run-time which is different from the way it looked at compile time. That is, the code was compiled with a classpath that included a different version of some library class from the version that has been loaded at runtime.

Two possible theories to investigate:

(a) In this case, on the face of it, all the classes involved seem to be Saxon classes, so this might suggest that you have more than one version of Saxon on the classpath, and for some reason code is being loaded from both.

(b) On the other hand, I can see right at the bottom of your screenshot, half-cropped, a line which suggests that you are using Saxon-EE with byte-code generation enabled, and this might indicate a bug in the byte-code generation. Try disabling byte-code generation to see if the problem goes away. For example by calling Processor.setConfigurationProperty(FeatureKeys.GENERATE_BYTECODE, false).

If it does turn out to be a bytecode generation bug, please log it at http://saxonica.plan.io, so we can track it properly. We will almost certainly need access to a stylesheet that demonstrates the problem.

Upvotes: 3

Related Questions