Tatu Saloranta

Ok just wanted to rule out any possibility of property-introspection fixes (which include improvements to Creator handling, which while essential to Records also affects Constructor usage by POJOs) in 2.18...

I am not quite sure what could be done here: yes, if a deserializer is to support `@JsonUnwrapped`, it must implement that method, to handle the case. I do not...

First: the comment referenced no longer exists in 2.18 codebase so I can't say for sure, but it seems misleading. Usually new instances are created and used to allow `JsonDeserializer`s...

(1) Ok so I cannot comment on Spring side of things -- although do note there is also `JsonMapper` sub-type of `ObjectMapper` (although "plain" ObjectMapper is, for historical reasons, JSON-specific)....

On (1)... I develop Jackson, not Spring, so I do not really know much about how it works. I do know a lot about Jackson. Not sure why this would...

(1) (on Spring) I do interact with Spring folks, but it definitely is more about them reporting bugs; I am just an occasional Spring (Boot) user, not developer. I don't...

Quick question: how would you represent such document without `~` marker? Wouldn't there be problem with `dsn` key conflicting -- that is, there being both: * quarkus.log.sentry = true *...

So could you not access `quarkus.log.sentry.dsn` in such case? Or is that simply dropped in such a case? If there is no equivalent document, I don't think Jackson data model...

Ohhh. Maybe it's effectively "empty" key? So something like JSON would have: ```json { "quarkus": { "log": { "sentry": { "": true, "dsn": "some string" } } } } ```...

Based on all of above, I am pretty sure we cannot, in general make this work: ``` assertTrue(node.get("quarkus").get("log").get("sentry").booleanValue()); ``` since `"sentry"` must be an Object value (with 2 logical properties;...