EXTERNAL_PROPERTY never gets deserialized

[benson-basis]

The branch named 'fiddle' in git@github.com:benson-basis/jackson-custom-mess-tc.git shows another wrinkle: an EXTERNAL_PROPERTY of class value with a @JsonValue annotation is deserialized to null.

#1270

[cowtowncoder]

I don't know if it is impossible to make @JsonValue work with polymorphic types, but it's certainly challenging and error prone. This because serialization would need to handle things apart: type information for "source" Java object, but content to serialize being of different actual type.
Combining this with external property I am not surprised it might not work.

[benson-basis]

I'm pretty sure I can see the failure even without JsonValue.

The type id resolution is working fine ... the problem is that the value
from the ext property gets lost on the way to its eventual home.

On Fri, Jun 17, 2016 at 4:12 PM, Tatu Saloranta notifications@github.com
wrote:

I don't know if it is impossible to make @JsonValue work with polymorphic
types, but it's certainly challenging and error prone. This because
serialization would need to handle things apart: type information for
"source" Java object, but content to serialize being of different actual
type.
Combining this with external property I am not surprised it might not work.

—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
#1271 (comment),
or mute the thread
https://github.com/notifications/unsubscribe/ADM9zwfn0aGmMTg-Pxf1yugiFOHP9yojks5qMv-XgaJpZM4I4k5w
.

[benson-basis]

The branch databind-1271 now demonstrates this without any use of JsonValue. The property called out as the EXTERNAL_PROPERTY is null after deserialization, even though was read and supplied to the type id resolver.

[cowtowncoder]

Ok yes, I can reproduce this with 2.8.0-SNAPSHOT. Addition of visible=true makes no difference, the only thing I tried so far.

One suggestion for actual code, if it differs from tests; instead of directly implementing TypeIdResolver, it's better to extend TypeIdResolverBase as that reduces clutter, and adds some protection against API changes (unfortunately there have been some here). Not related to the problem here, but thought worth mentioning.

[cowtowncoder]

Digging into this, no clear solution, but looking at existing failing tests seems like this might be same as #999: failure mode differs, but only because constructor validates the value.

[cowtowncoder]

Duplicate of #999, resolved by same fix, to be included in 2.8.0 (or 2.8.0.rc3 if one more rc was to be released).