[
https://issues.apache.org/jira/browse/CAMEL-26087?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Claus Ibsen resolved CAMEL-26087.
---------------------------------
Resolution: Fixed
Fixed by https://github.com/apache/camel/pull/28595, merged to main for 4.24.0.
_Claude Code on behalf of davsclaus_
> camel-stax - xtokenize fails on valid XML that starts with a comment or
> doctype, and mode 'w' fails or gives unbalanced wrappers when the matches are
> at different depths
> -------------------------------------------------------------------------------------------------------------------------------------------------------------------------
>
> Key: CAMEL-26087
> URL: https://issues.apache.org/jira/browse/CAMEL-26087
> Project: Camel
> Issue Type: Bug
> Components: camel-stax
> Reporter: shashank
> Assignee: shashank
> Priority: Major
> Fix For: 4.24.0
>
>
> Two cases where {{xtokenize}} ({{XMLTokenExpressionIterator}}, main
> 6a2f66ddec3e) fails on valid XML.
> # A document whose prolog has a comment or a doctype and no XML declaration
> fails in every mode with {{XMLStreamException: XMLStreamReader does not
> supporting getting location}} ({{<!-- generated by the order export
> -->\n<orders><order>1</order>...}}). The second compliance check (CAMEL-8164)
> treats text before the first start element that starts with {{<}} but not
> {{<?}} as proof of a reader without usable locations; with a compliant reader
> (Woodstox) that text is the prolog. Nothing is split and the message points
> at the StAX implementation.
> # Mode {{w}} with a descendant path whose matches are at different depths:
> {{<orders><order>1</order><box><order>2</order></box></orders>}} with
> {{xtokenize("//order", 'w')}} routes the first token and then fails with
> {{IndexOutOfBoundsException: Index -1 out of bounds for length 0}}; with a
> container inside a container of the same name a later token has an unbalanced
> wrapper ({{<orders><box><order>2</order></orders>}}). The segment log is
> popped by element name, but an element that starts right after a match has no
> entry of its own, and an inner element of the same name stops the pop too
> early.
> *Fix*: the compliance check looks at what the reader read after that text: a
> reader reporting the start of the start tag has the tag still ahead
> ({{<name}} followed by {{>}}, {{/}} or white space); Woodstox 7.3.0 does, the
> JDK reader reports the end of the tag and is still refused. Mode {{w}}
> records the depth of each segment and the end of an element removes the
> segments deeper than it; the preceding siblings kept in the wrapper
> (CAMEL-17466) are unchanged.
> *Tests*: new {{XMLTokenizePrologAndWrapDepthTest}}, 5 tests, all fail on main
> (the {{XMLStreamException}} above for a comment, a doctype and a comment
> containing the root's start tag; the {{IndexOutOfBoundsException}};
> {{Expected: <<orders><order>2</order></orders>> but was:
> <<orders><box><order>2</order></orders>>}}). Unit tests of camel-stax with
> the fix: 116 run, 0 failures, 2 skipped. A differential run against a DOM
> parser on 20,000 generated documents: on main 3,065 fail in every mode and
> mode {{w}} with {{//*:order}} fails on 633 more and gives 72 tokens that are
> not well-formed; with the fix none.
> *Related*: mode {{t}} does not decode entities and modes {{i}}/{{u}} cut the
> start tag at a {{>}} inside an attribute value: separate issue.
> *How it was found*: a reference differential of {{xtokenize}} against a DOM
> parser.
> *Affected*: main, camel-4.23.x, camel-4.22.x, camel-4.18.x and camel-4.14.x
> (same code). Read, not run.
> _Filed with Claude Code on behalf of allthingssecurity._
--
This message was sent by Atlassian Jira
(v10.3.26#10030026)
