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

Failure to resolve @RequestMapping method arguments in Servlet 2.5 environments [SPR-14358] #18930

spring-projects-issues opened this issue Jun 13, 2016 · 2 comments


Copy link

@spring-projects-issues spring-projects-issues commented Jun 13, 2016

Dmitri Gabbasov opened SPR-14358 and commented

Given the following bean configuration:

<?xml version="1.0" encoding="UTF-8"?>
<beans xmlns="" xmlns:xsi=""
  <context:component-scan base-package="test" />

and the following controller:

package test;
// ...
public class TestController {
  public String home(@RequestParam String param) {
    return param;

and using them in a Servlet 2.5 environment (e.g. Tomcat 6) will result in the following exception when a request is made to /home:

org.springframework.web.multipart.MultipartException: Current request is not a multipart request
        at org.springframework.web.method.annotation.RequestParamMethodArgumentResolver.handleMissingValue(
        at org.springframework.web.method.annotation.AbstractNamedValueMethodArgumentResolver.resolveArgument(
        at org.springframework.web.servlet.mvc.method.annotation.ServletInvocableHandlerMethod.invokeAndHandle(
        at org.springframework.web.servlet.mvc.method.annotation.RequestMappingHandlerAdapter.invokeHandlerMethod(
        at org.springframework.web.servlet.mvc.method.annotation.RequestMappingHandlerAdapter.handleInternal(
        at org.springframework.web.servlet.mvc.method.AbstractHandlerMethodAdapter.handle(
        at org.springframework.web.servlet.DispatcherServlet.doDispatch(
        at org.springframework.web.servlet.DispatcherServlet.doService(
        at org.springframework.web.servlet.FrameworkServlet.processRequest(
        at org.springframework.web.servlet.FrameworkServlet.doGet(
        at javax.servlet.http.HttpServlet.service(
        at org.springframework.web.servlet.FrameworkServlet.service(
        at javax.servlet.http.HttpServlet.service(

This only occurs when Spring chooses to use the RequestMappingHandlerAdapter (as opposed to the deprecated AnnotationMethodHandlerAdapter).

The root cause of this seems to be in the (somewhat recent) MultipartResolutionDelegate class. Its servletPartClass field remains null in pre Servlet 3.0 environments, and some equality checks yield false positives due to that. For instance:

private static boolean isPartCollection(MethodParameter methodParam) {
	return (servletPartClass == getCollectionParameterType(methodParam));
private static Class<?> getCollectionParameterType(MethodParameter methodParam) {
	Class<?> paramType = methodParam.getNestedParameterType();
	if (Collection.class == paramType || List.class.isAssignableFrom(paramType)){
		Class<?> valueType = GenericCollectionTypeResolver.getCollectionParameterType(methodParam);
		if (valueType != null) {
			return valueType;
	return null;

getCollectionParameterType returns null for non-collection parameters, which makes isPartCollection return true. The isPartArray method is plagued by the same issue (and maybe other places are too).

Affects: 4.3 GA

Issue Links:

  • #19030 MultipartResolutionDelegate in Servlet 2.5 environments not working correctly

Referenced from: commits dcb2c73

Copy link
Collaborator Author

@spring-projects-issues spring-projects-issues commented Jun 14, 2016

Juergen Hoeller commented

Good catch! Fixed for 4.3.1 now.

Copy link
Collaborator Author

@spring-projects-issues spring-projects-issues commented Jun 20, 2016

Francisco Lozano commented

Was about to report it, we were just hit by this. In our case, isPartCollection is the one hurting, glad it's already reported and fixed.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
2 participants