`DOMWrappingReader.getDepth()` is one too low at `START_ELEMENT`, and typed array reads lose a level

Aperta
  • Qualcosa non va?
#62 0 commenti 0 reazioni 0 assegnatari Vedi su GitHub

Nessuno ha ancora preso questa issue.

Valutazione

Difficoltà
3/5
Tempo stimato
1-2 giorni
Idoneità per principianti
58/100
Tipo di issue
Bug
Chiarezza
Specificata chiaramente
Stato di attività
Attiva
Stack tecnologico
java
Ambito
api

Direzione di ricerca

Start in DOMWrappingReader, where getDepth() returns _depth as is and readElementAsArray() moves into children or the virtual END_ELEMENT without the ++_depth that next() applies. Compare with Stax2ReaderAdapter.getDepth(), which is the reference for the expected values, and reproduce the two tables in the issue with a DOMSource. Done when getDepth() matches the expected values at START_ELEMENT, END_ELEMENT and after array reads, and the existing tests still pass. The compatibility impact on WstxDOMWrappingReader users needs a maintainer decision.

Scritto dal modello di indicizzazione a partire dal testo della issue.

Descrizione

Bug found when fixing #60, I'm afraid Claude is right here, too.
I can provide the PR if you wish.

XMLStreamReader2.getDepth() is documented as 1 at the root element itself, and the same for a start element and its matching end element. DOMWrappingReader breaks this in two ways:

  1. At every START_ELEMENT, getDepth() returns one less than it should. _depth is only incremented when next() moves past the start element, and getDepth() returns it as is. Values at END_ELEMENT and inside elements are correct.
  2. readElementAsArray() (and so readElementAsIntArray() etc.) permanently lowers the depth by one. Starting at START_ELEMENT, it moves into the children (or to the virtual END_ELEMENT of an empty element) without the ++_depth that next() does there, but leaving the END_ELEMENT still does --_depth. This happens for every array read, whether partial, complete or of an empty element. Each one lowers all later depths by one more.

This affects Woodstox too: WstxDOMWrappingReader, returned for any DOMSource, inherits both methods without overriding them. So its depths differ from Woodstox's own stream reader for the same document (TestXMLStreamReader2 in Woodstox checks the stream reader only; no DOM test checks getDepth()). Stax2ReaderAdapter reports the correct values in all cases below.

Repro (depth after each event):

Document, action Expected DOMWrappingReader
<root><a><b/></a>x<c/></root>, plain next() loop <root>1 <a>2 <b>3 </b>3 </a>2 x:1 <c>2 </c>2 </root>1 <root>0 <a>1 <b>2 </b>3 </a>2 x:1 <c>1 </c>2 </root>1
<root><a>1 2 3</a><b/></root>, <a> read with readElementAsIntArray() to the end <root>1 <a>2 </a>2 <b>2 </b>2 </root>1 <root>0 <a>1 </a>1 <b>0 </b>1 </root>0

Coalescing or not makes no difference. Same results for a partial read followed by next(), and for an empty <a/>.

Fix:

  1. getDepth(): return _depth+1 when the current event is START_ELEMENT. This mirrors the END_ELEMENT adjustment in Stax2ReaderAdapter.getDepth().
  2. readElementAsArray(): ++_depth when starting at START_ELEMENT, before either branch (children or empty element).

Checked with a temporary patch: all cases above then match Stax2ReaderAdapter, and the existing tests pass.

Compatibility: fix 1 changes the value callers get at every START_ELEMENT from a DOM reader, including Woodstox users with a DOMSource. Callers that adjusted for the old value will be off by one in the other direction. Fix 2 only changes behaviour after array reads, where the old values were wrong in any case.

Lingua principale
Java
Stelle
42
Fork
21
Merge medio
3h 50m
PR unite (30g)
2

Preparare l'ambiente

Questo progetto non fornisce container di sviluppo, Dockerfile né guida per i contributori, quindi l'ambiente è a tuo carico: parti dal suo README e consulta la nostra guida al primo contributo per i passaggi generali.

Come iniziare

  1. Leggi tutta la issue e poi la guida ai contributi del progetto.
  2. Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
  3. Fai un fork del repository e lavora su un branch.
  4. Apri una pull request che faccia riferimento al numero della issue.

Altre issue di FasterXML/stax2-api

Tutte le issue di FasterXML/stax2-api

Issue simili

Altre issue su Java

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.