Closed k163377 closed 1 week ago
I don't really like this test, as it tries to verify internal state, instead of showing externally observable problem: something users would hit. But perhaps this is because issue is otherwise hard to reproduce outside Kotlin module?
But even without that, test logic is pretty obscure: I don't think it really tests something documented to behave certain way.
But I'll play with the test, see what I can find.
But perhaps this is because issue is otherwise hard to reproduce outside Kotlin module?
That is correct. I would have liked to correct the problem, but the cause of such a result seems to be very deep, and it was difficult to analyze it without understanding the structure.
Ok that makes sense then.
Uhhh. Realized one mistake I made with naming: "Default Creator" already had a meaning in Jackson, pre-2.18 -- 0-argument Constructor/Factory method. So calling Record type's Canonical Contructor Default Creator adds unfortunate overloading. It really should have been called maybe Primary Creator. Not sure how I missed this conflict when thinking about naming because now:
AnnotationIntrospector
has new findDefaultCreator()
which is for finding such Primary creatorStdValueInstantiator
has _defaultCreator
which is specifically for 0-args Creator.Since I cannot really change API, some of this remains. But I may try to change code comments to better reflect new addition.
As to the change itself: I think only Constructors are detected as "default creators" on 2.18: explicitly annotated factory methods will all be considered as such, no special handling for 0-arg one. Databind works fine with that.
To change this, two approaches, both in POJOPropertiesCollector
(mostly?), could be tried:
ValueInstantiator
, see if there's explicitly annotated 0-args factory method collected (i.e. fix at a later point)@k163377 Ok, this is now fixed in 2.18
branch for 2.18.2. Could you see if this helps on Kotlin module side, with 2.18.2-SNAPSHOT of jackson-databind
?
I have confirmed that https://github.com/FasterXML/jackson-module-kotlin/issues/841 has been fixed. Thank you very much!
@k163377 Great! Thank you for confirming.
Search before asking
Describe the bug
This changes the behavior of
StdValueInstantiator
when deserializing, resulting in the following problem inkotlin-module
. https://github.com/FasterXML/jackson-module-kotlin/issues/841From @JooHyukKim 's research, this has changed the result of the
_vanillaProcessing
determination. https://github.com/FasterXML/jackson-module-kotlin/issues/841#issuecomment-2444178093I have confirmed that this value is populated by
StdValueInstantiator.configurationFromObjectSettings
, but have not been able to do a deeper analysis.Version Information
2.18
Reproduction
The following code succeeds in 2.17 but fails in 2.18.
Expected behavior
It must be the same as in 2.17.
Additional context
No response