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

Support for annotating multiple arguments with @RequestBody #24894

Closed
adiSuper94 opened this issue Apr 10, 2020 · 6 comments
Closed

Support for annotating multiple arguments with @RequestBody #24894

adiSuper94 opened this issue Apr 10, 2020 · 6 comments
Labels
in: web Issues in web modules (web, webmvc, webflux, websocket) status: declined A suggestion or change that we don't feel we should currently apply

Comments

@adiSuper94
Copy link

adiSuper94 commented Apr 10, 2020

I am using spring-webmvc 5.2.3.

I want to use Spring's Default MethodArgumentResolver to resolve the json payload into multiple beans. But I am not able to do that right now because AbstractMessageConverterMethodArgumentResolver.EmptyBodyCheckingHttpInputMessage(httpRequest)is passed the HttpRequest object and is used directly. While attempting to resolve the second argument the HttpRequest's inputStream is closed, so I get an exception saying that the input stream is closed. Ergo I am able to annotate only one argument with @RequestBody.

    @PostMapping("/endpoint")
    public void  method(@Valid @RequestBody CustomBean bean1, 
                                @Valid @RequestBody CustomBean2 bean2) 
    {
        // using both beans.
    }

Why not use a ContentCachingRequestWrapper instead of the actual HttpRequest for argument resolution ?

@spring-projects-issues spring-projects-issues added the status: waiting-for-triage An issue we've not yet triaged or decided on label Apr 10, 2020
@sbrannen sbrannen added the in: web Issues in web modules (web, webmvc, webflux, websocket) label Apr 10, 2020
@juzerali
Copy link

juzerali commented Apr 13, 2020

I think the problem is in AbstractJackson2HttpMessageConverter#readJavaType.

The converter passes requestBody of type InputStream directly to Jackson's ObjectReader#readValue, which closes the stream after parsing the JSON literal.

A temporary fix for you could be disabling the global JsonParser.Feature.AUTO_CLOSE_SOURCE flag in your env.

This can be fixed in Spring by adding .without(JsonParser.Feature.AUTO_CLOSE_SOURCE) in the call chain mentioned above. I can contribute with a PR.

juzerali added a commit to juzerali/spring-framework that referenced this issue Apr 13, 2020
@adiSuper94
Copy link
Author

adiSuper94 commented Apr 13, 2020

@juzerali , Agreed that marking JsonParser.Feature.AUTO_CLOSE_SOURCE as false will prevent the inputStream from being closed. But data that has been read once from a stream cannot be read again, right? How will adding AUTO_CLOSE_SOURCE = false help with this?

@sbrannen
Copy link
Member

I want to use Spring's Default MethodArgumentResolver to resolve the json payload into multiple beans.

When you say "multiple beans", do you perhaps mean multiple beans of different types?

I ask, because your example shows two beans of the exact same type (CustomBean) which doesn't seem to make much sense.

@adiSuper94
Copy link
Author

@sbrannen , yes I mean multiple beans of different types.
I'll change the code snippet for better clarity.

@juzerali
Copy link

You are right, it was a lame attempt. What do you think could be a solution?

@rstoyanchev
Copy link
Contributor

rstoyanchev commented Apr 14, 2020

So presumably the input is a JSON object that contains the data for both CustomBean1 and CustomBean2, in which case you could create one top-level object that contains both. Using a caching request wrapper could be another way to go, but that is not something we are going to do out of the box.

@rstoyanchev rstoyanchev added status: declined A suggestion or change that we don't feel we should currently apply and removed status: waiting-for-triage An issue we've not yet triaged or decided on labels Apr 14, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
in: web Issues in web modules (web, webmvc, webflux, websocket) status: declined A suggestion or change that we don't feel we should currently apply
Projects
None yet
Development

No branches or pull requests

5 participants