Fix #1654 (yet another attempt)

[cowtowncoder]

So, here's a bit more comprehensive attempt at #1654, assisted by Claude.

[cowtowncoder]

Ok, original test for #1654 passes. But I am not sure it's right at all -- it:

1. Has no custom serializer use
2. Custom deserializer does not seem to be used?

So handling of JsonTypeInfo.Id.NONE is fixed, but lookup for custom deserializer appears to be missing; and probably serializer too.

[JacksonJang]

Thanks for the follow-up!

I checked the behavior locally with the debugger,
and from what I can see both the custom serializer and the custom deserializer
are correctly used when JsonTypeInfo.Id.NONE is applied.

1. NoOpTypeSerializer
   • Breakpoint hits when serializing the target type

2. NoOpTypeDeserializer
   • Breakpoint hits during deserialization and the call stack correctly flows into the custom deserializer

I've attached the debugger screenshots showing both breakpoints being triggered.

[cowtowncoder]

@JacksonJang These are custom type deserializer/serializer (TypeDeserializer / TypeSerializer) and they are called ok as per fix.

But what seems to be missing are value (de)serializers (ValueDeserializer / ValueSerializer); added using @Json[De]Serialize(contentUsing = MyValue[De]Serializer.class).

So there are 2 different things.

Test has

        @JsonDeserialize(contentUsing = Value1654Deserializer.class)
        @JsonTypeInfo(use = JsonTypeInfo.Id.NONE)
        public List<Value1654> values;

but is missing

    @JsonSerialize(contentUsing = Value1654Serializer.class)

Hope this helps!

[cowtowncoder]

I think issue is probably best split in two: one wrt @JsonTypeInfo(use = JsonTypeInfo.Id.NONE) (now fixed) and follow-up for value (de)serializer overrides.

[JacksonJang]

Correction on my previous comment:
I re-checked the test case and found that the assertion in noTypeInfoOverrideDeser is incorrect.
The custom deserializer always returns new Value1654(13), but the test expects x = 7:

assertEquals(7, unResult.values.get(1).x);

If the custom deserializer is actually being invoked, both elements should have x = 13. The current assertion would only pass if the custom deserializer is not being used.

I'll fix the incorrect assertion (x=7 → x=13) and update the test to properly verify the custom deserializer invocation.

[cowtowncoder]

@JacksonJang Yes, but do note split between TypeDeserializer and ValueDeserializer (and same on serialization side). Former handles Type Ids (wrt @JsonTypeInfo), latter actual value itself.

So there are at least 2 aspects to resolve. This PR addresses one.

[JacksonJang]

@cowtowncoder
I’ve just submitted the PR with the code that successfully passed the latest test run.
Please take a look when you have a moment.

#5479