Empty List instead of null in List<MultipartFile> files [SPR-16329]

[spring-projects-issues]

Maciej Zerkowski opened SPR-16329 and commented

This is a followup to the following bug: #20472.

It seems that it's not possible to send null as List<MultipartFile> or MultipartFile[] in @RequestPart(value = "attachments", required = false) List<MultipartFile> files controller's method param. I tried PUT and POST.

---

Affects: 4.3.13

Issue Links:

• java.util.Optional MultipartFile[] @RequestParam argument is null in multipart/form-data POST [SPR-15918] #20472 java.util.Optional MultipartFile[] @RequestParam argument is null in multipart/form-data POST

Referenced from: commits 8f6d3fe

[spring-projects-issues]

Maciej Zerkowski commented

Is there a way to somehow workaround this issue? I tried to plug custom HandlerMethodArgumentResolver based on AbstractNamedValueMethodArgumentResolver with using WebMvcConfigurerAdapter but as it concerns annotations (@RequestPart in the above example) it doesn't even being triggered.

[spring-projects-issues]

Maciej Zerkowski commented

Ok I wrote my own RequestMappingHandlerAdapter overriting MultipartResolutionDelegate and it works fine.

[spring-projects-issues]

Maciej Zerkowski commented

It works as long as Pageable and Spring Data resolvers are not really needed. Then it throws: org.springframework.beans.BeanInstantiationException: Failed to instantiate org.springframework.data.domain.Pageable]: Specified class is an interface. I give up...

[spring-projects-issues]

Juergen Hoeller commented

It turns out that MultipartFile and also Servlet 3.0 Part collections are never non-existent but rather just empty (aligned with their corresponding accessors on (Multipart)HttpServletRequest), in contrast to plain request parameters where a parameter may be sent with one or more values or also no value at all (as per ServletRequest.getParameterValues).

As far as I can tell, this always worked like this and therefore isn't a regression either. I'm afraid this has to be seen as "works as designed": You'll have to check for an empty collection there.

[spring-projects-issues]

Maciej Zerkowski commented

No value at all will be also changed into emptyList.
"works as designed"? Hm. Quite strange - preventing sending null for MultipartFile collection. Moreover it is not so easy to change that behaviour - I had to remove annotation and introduce own MultipartFile wrapper to omit default resolvers.

[spring-projects-issues]

Juergen Hoeller commented

I should elaborate a bit: With multipart requests, there is a distinction between "no multipart request" and "no parts for the given name in a multipart request". The latter will resolve to an empty list (like in the corresponding Servlet APIs) whereas the former will resolve to null for a required=false parameter. This may arguably be a bit of a historic decision but it is what it is at this point.

Why do you absolutely need null for the List<MultipartFile> there? Couldn't you simply check for an empty list, even call downstream APIs with null if you prefer? Or declare the parameter as Optional and evaluate it through that little wrapper?

[spring-projects-issues]

Maciej Zerkowski commented

Thanks for the explanation but the thing is even if you have required=false parameter and you will not send anything - you will also get an emptyList for the type List<MultipartFile> or MultipartFile[] whatever it is @RequestParam or @RequestPart or even without any annotation. Unsinkable emptyList...

I use it for simple patern: emptyList - no changes to the collection, not empty - changes required, null - clear the collection.

I also didn't what to have Optional as a method paramether. But still it would be not very helpfull here.

[spring-projects-issues]

Maciej Zerkowski commented

The method signature I'm refering to: (@RequestPart Command command, <@RequestParam(required = false)|@RequestPart(required = false)> MultipartFile[]|List<MultipartFile> attachments)