Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Workaround for combining @JsonUnwrapped and @JsonTypeInfo? #4698

Open
1 task done
chris-dekker opened this issue Sep 13, 2024 · 3 comments
Open
1 task done

Workaround for combining @JsonUnwrapped and @JsonTypeInfo? #4698

chris-dekker opened this issue Sep 13, 2024 · 3 comments
Labels
has-failing-test Indicates that there exists a test case (under `failing/`) to reproduce the issue

Comments

@chris-dekker
Copy link

Search before asking

  • I searched in the issues and found nothing similar.

Describe the bug

It is currently not possible to combine @JsonUnwrapped with generic types using @JsonTypeInfo

Version Information

2.17.2

Reproduction

I have a generic Versioned<T> type containing a int version() and a payload T item(). I'd like to be able to (de)serialize this using @JsonUnwrapped, but cannot seem to get this to work together with the necessary @JsonTypeInfo to deal with the generic types.

Take the following types

  public record Inner(String foo, int bar) {}

  public record Versioned<T>(
      int version,
      @JsonUnwrapped @JsonTypeInfo(use = JsonTypeInfo.Id.CLASS, property = "@class") T item) {}

And the following example

    Versioned<Inner> example = new Versioned<>(1, new Inner("foo", 123));
    new ObjectMapper().writeValueAsString(example);

I would expect this produce the following JSON:

{
  "version": 1,
  "@class": "my.package.Inner",
  "foo": "foo",
  "bar": 123
}

But this does not work. Even when disabling SerializationFeature.FAIL_ON_UNWRAPPED_TYPE_IDENTIFIERS it still does drops the @class property, making deserialization fail.

Expected behavior

No response

Additional context

I found a bunch of threads from 10+ years ago where this was not supported through Jackson. I hope this has changed by now. It is not clear to me from this simple example why this is not supported.

Alternatively, I tried to create a manual StdSerializer and StdDeserializer but was unable to get the @JsonTypeInfo annotation to work. Any examples given would be great!

@chris-dekker chris-dekker added the to-evaluate Issue that has been received but not yet evaluated label Sep 13, 2024
@cowtowncoder
Copy link
Member

Quick note: I'd recommend trying this out with 2.18.0-rc1 since there have been many improvements to property introspection, specifically helping with record types.
The issue may still be there but it is good to rule out possibility of a fix.

@chris-dekker
Copy link
Author

Quick note: I'd recommend trying this out with 2.18.0-rc1 since there have been many improvements to property introspection, specifically helping with record types. The issue may still be there but it is good to rule out possibility of a fix.

Thanks for the tip! Gave it a try, but observing same issue. FWIW, the records are a mere example. The issue is the same with any POJO.

@cowtowncoder
Copy link
Member

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 might have helped.

But looking at this more closely... this won't work now, or possibly, ever.
Unwrapping only affects regular properties, not type ids -- polymorphic id is considered metadata and could not be moved around.

Further problems are conflict between generic and polymorphic types (won't play nicely).

So I suspect that to make things work, you will need to change the set up -- as things are declared this is unlikely to be workable with Jackson (at least without custom (de)serializers, but writing those is lots of work).

@cowtowncoder cowtowncoder added has-failing-test Indicates that there exists a test case (under `failing/`) to reproduce the issue and removed to-evaluate Issue that has been received but not yet evaluated labels Sep 13, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
has-failing-test Indicates that there exists a test case (under `failing/`) to reproduce the issue
Projects
None yet
Development

No branches or pull requests

2 participants