Jackson @JsonView deserialization support for request bodies [SPR-12501]

[spring-projects-issues]

Ersin Er opened SPR-12501 and commented

#11815 added support for @JsonView for response bodies. The same can also be applied to request bodies as Jackson already supports @JsonView for deserialization.

@RequestMapping(value = "/persons", consumes = APPLICATION_JSON_VALUE, method = RequestMethod.POST)
public ResponseEntity<Person> savePerson(@JsonView(View.Summary.class) @RequestBody Person p)
{
    return new ResponseEntity<>(personRepository.save(p), HttpStatus.OK);
}

---

Affects: 4.1.2

Attachments:

• SPR-12501.patch (5.83 kB)

Issue Links:

• Integrate Jackson @JsonView [SPR-7156] #11815 Integrate Jackson @JsonView
• JsonView support for JMS [SPR-13237] #17828 JsonView support for JMS
• Jackson @JsonView deserialization support for @MessageMapping payloads [SPR-13265] #17856 Jackson @JsonView deserialization support for @MessageMapping payloads
• Allow @JsonView to be used on meta-annotations on Rest methods [SPR-13268] #17859 Allow @JsonView to be used on meta-annotations on Rest methods

4 votes, 9 watchers

[spring-projects-issues]

Sébastien Deleuze commented

Hi Ersin Er,

Your proposal makes sense but @JsonView is currently not applicable to parameters, only to methods and fields.
I have raised an issue on Jackson bugtracker about that, let's see what is their answer.

Sébastien

[spring-projects-issues]

Sébastien Deleuze commented

Good news, starting Jackson 2.5.0 @JsonView will also target method parameters!

[spring-projects-issues]

Enrique Ruiz (DiSiD) commented

It would be great if the JSON data binding process would follow the same process of Validation, Data Binding, and Type Conversion than the one done by HTTP forms.

Imho the custom validations, data binding and type conversions would be able to be applied to both JSON messages and HTTP messages.

[spring-projects-issues]

Andrew Thorburn commented

I would love to see this feature, and I was having a look to see if I could get it working with just a few tweaks and maybe extending the jackson message converters, but no dice - the AbstractJackson2HttpMessageConverter has no idea what annotations are attached to the parameter, so it can't fetch the necessary annotation information - that's held one level up, by AbstractMessageConverterMethodArgumentResolver, but it's not passed into the actual message converter. Is there an easy way of dealing with this, or does it require broader changes to the Spring message conversion?

[spring-projects-issues]

Enrique Ruiz (DiSiD) commented

Sébastien, do you see this feature useful? Can we collaborate in any way?

[spring-projects-issues]

Sébastien Deleuze commented

Enrique Ruiz (DiSiD) Do you talk about "@JsonView deserialization support" or "JSON data binding process following the same process of Validation, Data Binding, and Type Conversion than HTTP forms" ?

[spring-projects-issues]

Mikhail Sokolov commented

I wrapped Type into ExtendedType that holds both originalType and additional info - view class. Look at the patch attached.

[spring-projects-issues]

Enrique Ruiz (DiSiD) commented

Hi Sébastien, I meant "JSON data binding process following the same process of Validation, Data Binding, and Type Conversion than HTTP forms" in spite of to use the Jackson2 data binding, validation and conversion process.

By doing that, a web application hasn't to define Type Conversion, Data Binding and Validation processes two times.

I think this isn't the right issue to comment about this theme, Sébastien could you point me where to report this improvement?

Thanks

[spring-projects-issues]

Sébastien Deleuze commented

Hi Enrique, could your request be related (at least partially) to #11715? I closed it as won't fix last year, but feel free to add a comment in this issue after reading the discussion.