You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
writeName's synthetic xsi:type handling forces attribute mode and the XSI namespace onto the next value, and only the bean-serializer path clears it (by assigning the next name through setNextName). For a Map / JsonNode whose first key is xsi:type:
every following sibling becomes an xsi:-prefixed attribute instead of an element (e.g. a List-valued sibling becomes duplicate xsi:list attributes)
{"xsi:type":"A","type":"B"} emits a duplicate xsi:type attribute, so the module produces XML it can no longer read back
{"xsi:type":"T","nil":"true"} emits xsi:nil="true", so the whole document reads back as null
Clears the forced state on the next writeName for the content-driven case, reverting to the enclosing element name so the following sibling keeps the enclosing namespace (same as it would without the xsi:type key). The bean path already reset it via setNextName, so legitimate polymorphic output is unchanged.
Note: an xsi:type key that is not first (after child elements have been written, as is always the case for @JsonAnyGetter maps following regular properties) still fails with "Trying to write an attribute when there is no open start element"; that is a pre-existing limitation not addressed here.
cowtowncoder
changed the title
clear forced xsi:type attribute state in ToXmlGenerator.writeName
Clear forced xsi:type attribute state in ToXmlGenerator.writeNameSep 15, 2026
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
cowtowncoder
changed the title
writeName's syntheticxsi:typehandling forces attribute mode and the XSI namespace onto the next value, and only the bean-serializer path clears it (by assigning the next name throughsetNextName). For aMap/JsonNodewhose first key isxsi:type:xsi:-prefixed attribute instead of an element (e.g. a List-valued sibling becomes duplicatexsi:listattributes){"xsi:type":"A","type":"B"}emits a duplicatexsi:typeattribute, so the module produces XML it can no longer read back{"xsi:type":"T","nil":"true"}emitsxsi:nil="true", so the whole document reads back asnullClears the forced state on the next
writeNamefor the content-driven case, reverting to the enclosing element name so the following sibling keeps the enclosing namespace (same as it would without thexsi:typekey). The bean path already reset it viasetNextName, so legitimate polymorphic output is unchanged.Note: an
xsi:typekey that is not first (after child elements have been written, as is always the case for@JsonAnyGettermaps following regular properties) still fails with "Trying to write an attribute when there is no open start element"; that is a pre-existing limitation not addressed here.