Add @JsonWrapped (to complement @JsonUnwrapped)

[lukens]

Re-rasing this issue from the old Jira bug tracker: https://jira.codehaus.org/browse/JACKSON-781

It was suggested this should be raised in the data bind project, but as it is an annotation, this seemed a better fit.

This is the original issue description:

@JsonUnwrapped allows people who want a more compressed JSON hierarchy than their POJO to affect the process, but there is no option for the reverse. I have a REST service producing unnecessary additional layers of abstraction that i would like to exclude from my Java POJOs rather than writing all sorts of unseemly wrapper classes.

I agree this would be a great feature to avoid unnecessary wrappers on the Java side when consuming JSON APIs.

I'd picture a new annotation that would take a form along the lines of:

@JsonWrapped("address")
@JsonProperty("house_number")
private String houseNumber;

or it could be an additional parameter of the @JsonProperty annotation:

@JsonProperty(value="house_number", wrapped="address")
private String houseNumber;

or, possibly, the value parameter of the @JsonProperty annotation could specify the object hierarchy:

@JsonProperty("address.house_number")
private String houseNumber;

This may introduce backwards compatibility issues, though, as it would mean this behaved differently than it currently does.

It would be good if it could also unwrap multiple levels, such as:

@JsonWrapped("contact_details.address")
@JsonProperty("house_number")
private String houseNumber;

Though, this would mean the value of the @JsonWrapped annotation was parsed differently than the value of the @JsonProperty annotation (as "contact_details.address" in the @JsonProperty annotation would refer to an object key named "contact_details.address").

[cowtowncoder]

You are right in that annotation itself would be added here, but none of code handling it will be, which is why I think databind is actually better place for this.
But that's fine; we can even just have 2 issues, one for annotation, one for handling, mostly just to have entries for release notes for both.

As to multiple levels, I thought about that, and if that was to be supposed, I don't think we can assume '.' can be used as separator, since it is a legal property name character.
But changing this to allow sequence of ids is easy, like:

@JsonWrapped({ "contact_details", "address" })

and Java annotations also allow omitting arrays to just do single as well

@JsonWrapped("single")

[codeallthethingz]

👍

[geota]

👍

[asafdav2]

+1

[sadlerjw]

+1. I'd love if this were added to @JsonProperty with the optional array syntax @cowtowncoder suggested:

@JsonProperty({"address", "housenumber"})

[mrolla]

This would save a lot of boilerplate. +1

[natnan]

👍

[thomaseizinger]

I would also like to see this feature.
Is there a workaround for this? Especially in combination with mixins?

[cowtowncoder]

Currently custom serialializer/deserializer would be the way to go. Or possibly converting serializer/deserializer using disposable wrapper classes.

[meshuga]

+1 for

@JsonWrapped({ "contact_details", "address" })

[Redliver]

+1

[peruzzo]

+1

[ghost]

+1

[djechelon]

+1

[cowtowncoder]

Enough voting -- locking issue for now, hoping github will add something better than needing to add more +1 comments. :)

[cowtowncoder]

Unlocking to allow use of reactions (use "thumbs up" to "vote"). Please no "+1" comments (content-containing comments welcome of course).