-
-
Notifications
You must be signed in to change notification settings - Fork 6.6k
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
[Spring] replace MultipartFile by Resource #18509
Conversation
Should this not be a MultipartFileResource? |
Good question. I used I anyway wanted to try (Since So I guess I'll keep using |
Hey @martin-mfg Iam unsure if really Resource is right for a Multipart. I don't know why the other API are using it. We are using MultipartFile and there is method
Did you try if a resource is really working as MultiPart? Or can you then cast the Resource to a MultiPartResource? |
SpringCodegen briefly used MultipartFile in the past, but then switched (back) to Resource. see #9555 for the change itself, and the links there for people encountering problems with MultipartFile.
Yes, the generated server works and can receive multipart requests.
The actual type of the Resource parameter was ByteArrayResource in my test. But I guess this depends on the concrete input spec. And Resource can not be cast to MultiPart(Resource). Can you explain a bit more what problems you see with using Resource? It sounds like you already have a generated spring server which uses MultiPartFile. But as described in #18345, this shouldn't even compile in the first place. Anyway, I do agree that MultiPartFile might actually be more useful than Resource, if the problems from #9555 can be avoided. But in that case I would like to keep the focus of this PR on fixing the compilation problem described in #18345. Making SpringCodegen generally use MultiPartFile instead of Resource should then be a separate PR. Does that sound good to you? |
Currently we have Spring Api with MultiPart. I can check my settings and which version. We also use the generated Spring Client. So this will then break our current Api and client. That's my point. And we need for a bigger upload a multipart. I will look into the issue on monday or tuesday and come back with my generated code + settings |
That's the generated code with open api generator 7.5.0 Spring Java
Open API yaml
Maven setting
And here is the spring guide: |
Thanks for the input. I didn't have time to take a closer look yet, and this week I won't be available. But this PR is still on my to-do-list. |
Looks good for me |
fix #18345
To reproduce the problem, it's sufficient to use the
spring
generator withdelegatePattern=true
on this input:The output doesn't compile.
(edit: added mention of delegatePattern and fixed the input spec above.)
As far as I can tell, the
spring
generator was meant to switch to usingResource
instead ofMultipartFile
in all cases. But some places in the templates were not adjusted. I did this now in this PR. And it worked well in all scenarios I could test.(The server generated here runs, but requests to the /multipart-mixed endpoint didn't work out of the box for me, due to "Unsupported Media Type". Both before and after my changes. So that's probably a different issue.)
PR checklist
Commit all changed files.
This is important, as CI jobs will verify all generator outputs of your HEAD commit as it would merge with master.
These must match the expectations made by your contribution.
You may regenerate an individual generator by passing the relevant config(s) as an argument to the script, for example
./bin/generate-samples.sh bin/configs/java*
.IMPORTANT: Do NOT purge/delete any folders/files (e.g. tests) when regenerating the samples as manually written tests may be removed.
master
(upcoming 7.1.0 minor release - breaking changes with fallbacks),8.0.x
(breaking changes without fallbacks)@cachescrubber (2022/02) @welshm (2022/02) @MelleD (2022/02) @atextor (2022/02) @manedev79 (2022/02) @javisst (2022/02) @borsch (2022/02) @banlevente (2022/02) @Zomzog (2022/09) @martin-mfg (2023/08)