recompute XML metadata for filtered props in XmlBeanSerializerBase - #907
Open
Sahana2524 wants to merge 1 commit into
Open
recompute XML metadata for filtered props in XmlBeanSerializerBase#907Sahana2524 wants to merge 1 commit into
Sahana2524 wants to merge 1 commit into
Conversation
🧪 Code Coverage Report
|
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
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
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.
Wrong-property XML metadata after
@JsonIgnorePropertiesXmlBeanSerializerBasekeeps four index-parallel structures (_attributeCount,_textPropertyIndex,_xmlNames,_cdata) that the base constructor derives from_props. The(src, toIgnore, toInclude)and(src, properties, filteredProperties)constructors copied them straight fromsrc, butsuper(...)there rebuilds_propswith a shorter or re-ordered set, so every slot after a dropped or moved property lands on the wrong one. A member-level@JsonIgnoreProperties/@JsonIncludeProperties(which routes throughwithByNameInclusion) or a modifier that hands backwithProperties(...)is enough to hit it, and nothing throws: a plain element gets emitted as an attribute, a@JacksonXmlTextvalue swaps places with the next element, or CDATA attaches to a neighbor, so the output no longer reads back to the same object.Moved the derivation into a shared helper and recomputed it against the rebuilt array in those two constructors; the copy-from-
srcpath stays for the constructors that keep the same property set. Added regression tests for the attribute, text, and CDATA cases (each fails before the change). Full suite green under./mvnw -B -ff -ntp verify.