RequestPartMethodArgumentResolver should defensively handle MethodParameter nesting level and java.util.Optional access [SPR-13850]

[spring-projects-issues]

Juergen Hoeller opened SPR-13850 and commented

RequestPartMethodArgumentResolver contains a conditional code path with a Optional.ofNullable call. While this will work in most pre-Java-8 environments as well, it's fragile in debug environments, in particular on the IBM JVM. We should defensively delegate to an inner class with the actual Optional reference, like we do in other places.

Also, RequestPartMethodArgumentResolver modifies the nesting level of a potentially cached MethodParameter instance. This should be avoided in favor of temporary nested type access or a MethodParameter clone.

---

Affects: 4.2.4

Issue Links:

• Make @ResponseBody method return type available to message converters [SPR-12811] #17408 Make @ResponseBody method return type available to message converters
• Support for java.util.Optional as a @RequestPart [SPR-12644] #17245 Support for java.util.Optional as a @RequestPart
• Request parameters cannot bind to Optional<List<String>> [SPR-13418] #17997 Request parameters cannot bind to Optional<List>
• MultipartFile argument requires multipart request even when optional (and empty) [SPR-13849] #18422 MultipartFile argument requires multipart request even when optional (and empty)
• Part list/array gets resolved to all parts in current request [SPR-13893] #18467 Part list/array gets resolved to all parts in current request

Referenced from: commits 3779fe9, a58eee6, b4f33ad