Second call to MVC handler method with Optional parameter fails with argument type mismatch [SPR-13755]

[spring-projects-issues]

Andy Wilkinson opened SPR-13755 and commented

This was originally reported as a Spring Boot issue, but I believe the problem lies in Spring MVC. I've pushed a sample that reproduces the issue to the spring-boot-issues repo: https://github.com/spring-projects/spring-boot-issues/tree/master/gh-4660.

For the first request, the argument type is correctly resolved as java.util.Optional. The second time it's resolved as a MultipartFile. A possible side-effect of the first resolution setting the HandlerMethodParameter's parameter type so the second resolution is using different inputs?

---

Affects: 4.1.8, 4.2.3

Reference URL: spring-projects/spring-boot#4660

Issue Links:

• Support for java.util.Optional as a @RequestPart [SPR-12644] #17245 Support for java.util.Optional as a @RequestPart

Backported to: 4.1.9

[spring-projects-issues]

Juergen Hoeller commented

Indeed, its the interaction with GenericTypeResolver.resolveParameterType which breaks it: There is a missing check for the top nesting level there, accidentally exposing a nested parameter type as cached top-level parameter type.

The underlying bug also affects 4.1.x, so I'm backporting that change to 4.1.9 as well.

Juergen

[spring-projects-issues]

Juergen Hoeller commented

Andy Wilkinson, does a recent 4.2.4.BUILD-SNAPSHOT work here? Could you please (re-)run that Boot repro app just to double-check?

Juergen

[spring-projects-issues]

Andy Wilkinson commented

Looks good. The repro passes against Boot 1.3.1.BUILD-SNAPSHOT which is using Spring Framework 4.2.4.BUILD-SNAPSHOT.