Repository navigation
Honor @JsonIgnoreType for Creator properties - #6284
aysha-afrah26 wants to merge 2 commits into
Conversation
Type-based ignoral was skipped for properties with a constructor parameter, so a property-based Creator parameter or Record component of an ignored type still bound from input. Register such names as ignorable like explicitly ignored ones, so the Creator property is marked ignorable during resolve().
Code Review ✅ Approved 1 closed / 1 findings🟡 Medium risk Honors ✅ 1 closed✅ Edge Case: Ignored-type Creator params now fail with FAIL_ON_MISSING_CREATOR_PROPERTIES
VerificationRules No rules evaluated Functional validation Not enabledFor more verification details, comment OptionsAuto-apply is off → Gitar will not commit updates to this branch. Comment with these commands to change the behavior for this request:
Was this helpful? React with 👍 / 👎 | Powered by Gitar — free for open source |
@JsonIgnoreType(andsetIsIgnoredType(true)config overrides) is applied inBeanDeserializerFactory.filterBeanProps(), but only to properties without a constructor parameter, so a property-based@JsonCreatorparameter or a Record component of an ignored type still binds from input. Withrecord Account(String name, Credentials creds)andCredentialsmarked@JsonIgnoreType, serialization dropscredsas expected, yet{"name":"bob","creds":{"role":"admin"}}reads back with a populatedCredentials, while the same type as a field, setter or builder property is skipped. So request JSON can populate a type the application declared off-limits whenever that type reaches the object through a Creator. I ran into it while comparing ignoral handling between Creator and setter-based properties. Dropping the constructor-parameter exemption routes these properties throughbuilder.addIgnorable(), the same way explicitly ignored names already are, soBeanDeserializerBase.resolve()marks the Creator property ignorable and the constructor getsnullinstead of the input value. The new tests inIgnoredTypesTest(Creator, Record, config override) fail on 3.1 without the change, and full./mvnw verifypasses with it. Same code is on 3.2, 3.x and 2.x; targeting 3.1 as the LTS line, and since this touches the same block offilterBeanProps()as #6202, whichever lands second needs a trivial rebase.