xsl: сортировать внутри для каждой группы()

По какой-то причине xsl: sort внутри группы для каждой группы выдает исключение после обновления до 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>

Ошибка-

введите здесь описание изображения

Просто хочу проверить, является ли это ошибкой в ​​Saxon или что-то изменилось в том, как это работало в XSLT 3.0.


xml xslt saxon xslt-3.0
person Vinit    schedule 06.01.2016    source источник
comment
Я могу воспроизвести проблему с 9.7 EE, но не с PE или HE. Вы тоже пользуетесь ЕЕ?   -  person Martin Honnen    schedule 06.01.2016

Ответы (2)


arrow_upward
3
arrow_downward

IncompatibleClassChangeError обычно означает, что есть класс, загруженный JVM во время выполнения, который отличается от того, как он выглядел во время компиляции. То есть код был скомпилирован с путем к классам, который включал версию некоторого библиотечного класса, отличную от версии, которая была загружена во время выполнения.

Две возможные теории для исследования:

(a) В этом случае, на первый взгляд, все задействованные классы кажутся классами Saxon, поэтому это может указывать на то, что у вас есть более одной версии Saxon в пути к классам, и по какой-то причине код загружается из обоих .

(b) С другой стороны, я вижу в самом низу вашего снимка экрана, наполовину обрезанную, строку, которая предполагает, что вы используете Saxon-EE с включенной генерацией байт-кода, и это может указывать на ошибку в байтовом коде. -генерация кода. Попробуйте отключить генерацию байт-кода, чтобы увидеть, исчезнет ли проблема. Например, позвонив Processor.setConfigurationProperty(FeatureKeys.GENERATE_BYTECODE, false).

Если это действительно ошибка генерации байт-кода, зарегистрируйте ее на странице http://saxonica.plan.io. , чтобы мы могли отслеживать его должным образом. Нам почти наверняка понадобится доступ к таблице стилей, демонстрирующей проблему.

person Michael Kay    schedule 06.01.2016
comment
Спасибо за ваш ответ. Только что убедился, что в проекте используется только одна саксонская банка. Мы проверяем, включена ли генерация байт-кода или нет. - person Vinit; 06.01.2016
comment
Оказывается, у нас включена генерация байт-кода. Это исчезнет, ​​если мы его отключим. Вот проблема: saxonica.plan.io/issues/2573 - person Vinit; 07.01.2016

arrow_upward
1
arrow_downward

Я не думаю, что это настоящее исправление, но, как ни странно, вы можете добавить оператор <xsl:value-of select="current-grouping-key()"/> в тело для каждой группы, и исключение исчезнет. Можно в комментарии.

<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>
person Caroline S    schedule 07.01.2016
comment
На самом деле совсем не таинственно. Крошечные изменения в таблице стилей могут увести оптимизатор по совершенно другому пути, что приведет к существенному изменению планов выполнения. Вот почему нам обычно нужна копия, которая действительно демонстрирует проблему, а не просто фрагмент кода. (Спасибо за поставку один). - person Michael Kay; 07.01.2016
comment
Хотя причины в этом случае оказываются интересными и обсуждаются в записи об ошибках Saxon. - person Michael Kay; 07.01.2016