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
Jackson checks the @JsonIgnoreProperties set before assigning a Creator property, since a type with a property-based @JsonCreator resolves a valid creatorProp and so never falls through to the by-name ignore check later in the same loop. That guard reached deserializeUsingPropertyBased and deserializeUsingPropertyBasedWithUnwrapped, but it never reached deserializeUsingPropertyBasedWithExternalTypeId, and BuilderBasedDeserializer carries no copy of it at all. The effect is that ignoring a property works for a plain POJO or record and quietly stops working for the same type once it is built through a @JsonPOJOBuilder, or once it gains an @JsonTypeInfo(include = EXTERNAL_PROPERTY) property, so a value the application excluded from binding is read off the document and handed to the constructor. I noticed it while comparing a builder-backed type with the equivalent plain Creator type and getting different results for identical input. The fix adds the check the sibling loops already use, right after the existing isInjectionOnly test, at the three loops that lack it. Reported separately as #6145, which has a runnable reproduction for each of the three; the new test fails on all three before this change and passes after, and the rest of the suite is unchanged. I left 3.1 alone on purpose, because its copy of the guard is deliberately limited to records, so applying this there would widen behavior instead of closing a gap.
The reason will be displayed to describe this comment to others. Learn more.
Minor/optional: Since this test exercises the @JsonUnwrapped path, would it also make sense to assert result.child.name.last == "Smith"? That would explicitly verify that skipping the ignored Creator property doesn't affect deserialization of the remaining unwrapped properties.
The fix as written really only fits 3.2+: on 3.1 the #4629 guard is still gated on isRecord (records-only by design), so honoring ignoral for regular POJO Creator props is behavior that starts in 3.2, and this PR just extends 3.2's existing guard to the three loops that missed it. Porting it to 3.1 as-is would broaden that records-only behavior on a maintenance branch rather than close a gap, which is why I targeted 3.2. If you do want something on 3.1, the scope-preserving option would be an isRecord-gated check on just the external-type-id loop (builders can't be records, so the other two sites wouldn't apply); happy to put that together if you'd like it there.
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.
Jackson checks the
@JsonIgnorePropertiesset before assigning a Creator property, since a type with a property-based@JsonCreatorresolves a validcreatorPropand so never falls through to the by-name ignore check later in the same loop. That guard reacheddeserializeUsingPropertyBasedanddeserializeUsingPropertyBasedWithUnwrapped, but it never reacheddeserializeUsingPropertyBasedWithExternalTypeId, andBuilderBasedDeserializercarries no copy of it at all. The effect is that ignoring a property works for a plain POJO or record and quietly stops working for the same type once it is built through a@JsonPOJOBuilder, or once it gains an@JsonTypeInfo(include = EXTERNAL_PROPERTY)property, so a value the application excluded from binding is read off the document and handed to the constructor. I noticed it while comparing a builder-backed type with the equivalent plain Creator type and getting different results for identical input. The fix adds the check the sibling loops already use, right after the existingisInjectionOnlytest, at the three loops that lack it. Reported separately as #6145, which has a runnable reproduction for each of the three; the new test fails on all three before this change and passes after, and the rest of the suite is unchanged. I left3.1alone on purpose, because its copy of the guard is deliberately limited to records, so applying this there would widen behavior instead of closing a gap.