HandlerMethodArgumentResolver三基于消息转换器的参数处理器享学Spring-MVC

jiezi

5 年前

一个事实是：对于大多数技术，了解只需要一天，简单搞起来只需要一周。入门可能只需要一个月

通过前面两篇文章的介绍，相信你对 HandlerMethodArgumentResolver 了解已经很深刻了。但是你或许和我一样还有一种感觉，似乎还缺点什么：
我们使用非常频繁的 @RequestBody 是怎么封装请求体的呢？？？这块使用非常广泛的地方却还木有讲解到，因为它的处理方式和前面的不太一样，因此单摘出来到本文进行详细描述。

第四类：基于 `ContentType` 消息转换器类型

利用 HttpMessageConverter 将输入流 转换成对应的参数

这类参数解析器的基类是AbstractMessageConverterMethodArgumentResolver：

// @since 3.1
public abstract class AbstractMessageConverterMethodArgumentResolver implements HandlerMethodArgumentResolver {

    // 默认支持的方法（没有 Deleted 方法）// httpMethod 为 null 或者方法不属于这集中 或者没有 contendType 且没有 body 那就返回 null
    // 也就是说如果是 Deleted 请求，即使 body 里有值也是返回 null 的。（因为它不是 SUPPORTED_METHODS）private static final Set<HttpMethod> SUPPORTED_METHODS = EnumSet.of(HttpMethod.POST, HttpMethod.PUT, HttpMethod.PATCH);
    private static final Object NO_VALUE = new Object();

    protected final List<HttpMessageConverter<?>> messageConverters;
    protected final List<MediaType> allSupportedMediaTypes;
    // 和 RequestBodyAdvice 和 ResponseBodyAdvice 有关的
    private final RequestResponseBodyAdviceChain advice;

    // 构造函数里指定 HttpMessageConverter
    // 此一个参数的构造函数木人调用
    public AbstractMessageConverterMethodArgumentResolver(List<HttpMessageConverter<?>> converters) {this(converters, null);
    }

    // @since 4.2
    public AbstractMessageConverterMethodArgumentResolver(List<HttpMessageConverter<?>> converters, @Nullable List<Object> requestResponseBodyAdvice) {Assert.notEmpty(converters, "'messageConverters' must not be empty");
        this.messageConverters = converters;
        // 它会把所有的消息转换器里支持的 MediaType 都全部拿出来汇聚起来~
        this.allSupportedMediaTypes = getAllSupportedMediaTypes(converters);
        this.advice = new RequestResponseBodyAdviceChain(requestResponseBodyAdvice);
    }

    // 提供一个 defualt 方法访问
    RequestResponseBodyAdviceChain getAdvice() {return this.advice;}

    // 子类 RequestResponseBodyMethodProcessor 有复写此方法
    @Nullable
    protected <T> Object readWithMessageConverters(NativeWebRequest webRequest, MethodParameter parameter, Type paramType) throws IOException, HttpMediaTypeNotSupportedException, HttpMessageNotReadableException {HttpInputMessage inputMessage = createInputMessage(webRequest);
        return readWithMessageConverters(inputMessage, parameter, paramType);
    }
    ...
}

说明：此抽象类并没有实现 resolveArgument() 这个接口方法，而只是提供了一些 protected 方法，作为工具方法给子类调用，比如最为重要的这个方法：readWithMessageConverters()就是利用消息转换器解析 HttpInputMessage 的核心。

关于此抽象类的描述，可以看这里，HttpMessageConverter 匹配规则

它的继承树如下：

它用于解析参数被 @RequestPart 修饰，或者参数类型是 MultipartFile | Servlet 3.0 提供的 javax.servlet.http.Part 类型（并且没有被 @RequestParam 修饰），数据通过 HttpServletRequest获取

当属性被标注为 @RequestPart 的话，那就会经过 HttpMessageConverter 结合 Content-Type 来解析，这个效果特别像 @RequestBody 的处理方式~

// @since 3.1
@Target(ElementType.PARAMETER)
@Retention(RetentionPolicy.RUNTIME)
@Documented
public @interface RequestPart {@AliasFor("name")
    String value() default "";
    @AliasFor("value")
    String name() default "";
    boolean required() default true;}

// @since 3.1
public class RequestPartMethodArgumentResolver extends AbstractMessageConverterMethodArgumentResolver {

    // 标注了 @RequestPart 注解的
    // 没有标注 @RequestPart 并且也没有标注 @RequestParam，但是是 Multipart 类型的也会处理
    @Override
    public boolean supportsParameter(MethodParameter parameter) {if (parameter.hasParameterAnnotation(RequestPart.class)) {return true;} else {if (parameter.hasParameterAnnotation(RequestParam.class)) {return false;}
            return MultipartResolutionDelegate.isMultipartArgument(parameter.nestedIfOptional());
        }
    }

    @Override
    @Nullable
    public Object resolveArgument(MethodParameter parameter, @Nullable ModelAndViewContainer mavContainer,
            NativeWebRequest request, @Nullable WebDataBinderFactory binderFactory) throws Exception {HttpServletRequest servletRequest = request.getNativeRequest(HttpServletRequest.class);
        Assert.state(servletRequest != null, "No HttpServletRequest");

        RequestPart requestPart = parameter.getParameterAnnotation(RequestPart.class);
        boolean isRequired = ((requestPart == null || requestPart.required()) && !parameter.isOptional());

        // 如果注解没有指定，就取形参名
        String name = getPartName(parameter, requestPart);
        parameter = parameter.nestedIfOptional();
        Object arg = null;

        // resolveMultipartArgument 这个方法只处理：// MultipartFile 类型以及对应的数组 / 集合类型
        // Part 类型以及对应的数组集合类型
        // 若形参类型不是以上类型，返回 UNRESOLVABLE（空对象）// 最终返回 StandardMultipartHttpServletRequest/request.getParts()[0]等~
        Object mpArg = MultipartResolutionDelegate.resolveMultipartArgument(name, parameter, servletRequest);
        if (mpArg != MultipartResolutionDelegate.UNRESOLVABLE) {arg = mpArg; // 是 part 类型，那就直接赋值吧} else { // 其它类型
            ...
        }
        ...
    }
}

此处理器用于解析 @RequestPart 参数类型，它和多部分文件上传有关。关于 Spring MVC 中的文件上传，此处就不便展开了。后面有个专题专门讲解 Spring MVC 中的上传、下载~

命名为 Processor 说明它既能处理入参，也能处理返回值，当然本文的关注点是方法入参（和 HttpMessageConverter 相关）。

请求 body 体 一般是一段字符串 / 字节流，查询参数可以看做 URL 的一部分，这两个是位于请求报文的不同地方。

表单参数可以按照一定格式放在请求体中，也可以放在 url 上作为查询参数。

响应 body 体 则是 response 返回的具体内容，对于一个普通的 html 页面，body 里面就是页面的源代码。对于 HttpMessage 响应体里可能就是个 json 串（但无强制要求）。

响应体一般都会结合 Content-Type 一起使用，告诉客户端只有知道这个头了才知道如何渲染。

AbstractMessageConverterMethodProcessor 源码稍显复杂，它和 Http 协议、内容协商有很大的关联：

// @since 3.1
public abstract class AbstractMessageConverterMethodProcessor extends AbstractMessageConverterMethodArgumentResolver implements HandlerMethodReturnValueHandler {

    // 默认情况下：文件们后缀是这些就不弹窗下载
    private static final Set<String> WHITELISTED_EXTENSIONS = new HashSet<>(Arrays.asList("txt", "text", "yml", "properties", "csv",
            "json", "xml", "atom", "rss", "png", "jpe", "jpeg", "jpg", "gif", "wbmp", "bmp"));
    private static final Set<String> WHITELISTED_MEDIA_BASE_TYPES = new HashSet<>(Arrays.asList("audio", "image", "video"));
    private static final List<MediaType> ALL_APPLICATION_MEDIA_TYPES = Arrays.asList(MediaType.ALL, new MediaType("application"));
    private static final Type RESOURCE_REGION_LIST_TYPE = new ParameterizedTypeReference<List<ResourceRegion>>() {}.getType();
    
    // 用于给 URL 解码 decodingUrlPathHelper.decodeRequestString(servletRequest, filename);
    private static final UrlPathHelper decodingUrlPathHelper = new UrlPathHelper();
    // rawUrlPathHelper.getOriginatingRequestUri(servletRequest);
    private static final UrlPathHelper rawUrlPathHelper = new UrlPathHelper();
    static {rawUrlPathHelper.setRemoveSemicolonContent(false);
        rawUrlPathHelper.setUrlDecode(false);
    }

    // 内容协商管理器
    private final ContentNegotiationManager contentNegotiationManager;
    // 扩展名的内容协商策略
    private final PathExtensionContentNegotiationStrategy pathStrategy;
    private final Set<String> safeExtensions = new HashSet<>();

    protected AbstractMessageConverterMethodProcessor(List<HttpMessageConverter<?>> converters) {this(converters, null, null);
    }
    // 可以指定内容协商管理器 ContentNegotiationManager 
    protected AbstractMessageConverterMethodProcessor(List<HttpMessageConverter<?>> converters, @Nullable ContentNegotiationManager contentNegotiationManager) {this(converters, contentNegotiationManager, null);
    }
    // 这个构造器才是重点
    protected AbstractMessageConverterMethodProcessor(List<HttpMessageConverter<?>> converters, @Nullable ContentNegotiationManager manager, @Nullable List<Object> requestResponseBodyAdvice) {super(converters, requestResponseBodyAdvice);

        // 可以看到：默认情况下会直接 new 一个
        this.contentNegotiationManager = (manager != null ? manager : new ContentNegotiationManager());
        // 若管理器里有就用管理器里的，否则 new PathExtensionContentNegotiationStrategy()
        this.pathStrategy = initPathStrategy(this.contentNegotiationManager);

        // 用 safeExtensions 装上内容协商所支持的所有后缀
        // 并且把后缀白名单也加上去（表示是默认支持的后缀）this.safeExtensions.addAll(this.contentNegotiationManager.getAllFileExtensions());
        this.safeExtensions.addAll(WHITELISTED_EXTENSIONS);
    }

    // ServletServerHttpResponse 是对 HttpServletResponse 的包装，主要是对响应头进行处理
    // 主要是处理：setContentType、setCharacterEncoding 等等
    // 所以子类若要写数据，就调用此方法来向输出流里写吧~~~
    protected ServletServerHttpResponse createOutputMessage(NativeWebRequest webRequest) {HttpServletResponse response = webRequest.getNativeResponse(HttpServletResponse.class);
        Assert.state(response != null, "No HttpServletResponse");
        return new ServletServerHttpResponse(response);
    }

    // 注意：createInputMessage()方法是父类提供的，对 HttpServletRequest 的包装
    // 主要处理了：getURI()、getHeaders()等方法
    // getHeaders()方法主要是处理了：getContentType()...


    protected <T> void writeWithMessageConverters(T value, MethodParameter returnType, NativeWebRequest webRequest) throws IOException, HttpMediaTypeNotAcceptableException, HttpMessageNotWritableException {ServletServerHttpRequest inputMessage = createInputMessage(webRequest);
        ServletServerHttpResponse outputMessage = createOutputMessage(webRequest);
        writeWithMessageConverters(value, returnType, inputMessage, outputMessage);
    }

    // 这个方法省略
    // 这个方法是消息处理的核心之核心：处理了 contentType、消息转换、内容协商、下载等等
    // 注意：此处并且还会执行 RequestResponseBodyAdviceChain，进行前后拦截
    protected <T> void writeWithMessageConverters(@Nullable T value, MethodParameter returnType,
            ServletServerHttpRequest inputMessage, ServletServerHttpResponse outputMessage)
            throws IOException, HttpMediaTypeNotAcceptableException, HttpMessageNotWritableException {...}
}

本类的核心是各式各样的 HttpMessageConverter 消息转换器，因为最终的 write 都是交给它们去完成。
此抽象类里，它完成了内容协商~

关于内容协商的详解，强烈建议你点击这里。另外这篇文章也深入的分析了 AbstractMessageConverterMethodProcessor 这个类，可以作为参考。

既然父类都已经完成了这么多事，那么子类自然就非常的简单的。看看它的两个具体实现子类：

RequestResponseBodyMethodProcessor

顾名思义，它负责处理 @RequestBody 这个注解的参数

public class RequestResponseBodyMethodProcessor extends AbstractMessageConverterMethodProcessor {
    @Override
    public boolean supportsParameter(MethodParameter parameter) {return parameter.hasParameterAnnotation(RequestBody.class);
    }

    @Override
    public Object resolveArgument(MethodParameter parameter, @Nullable ModelAndViewContainer mavContainer, NativeWebRequest webRequest, @Nullable WebDataBinderFactory binderFactory) throws Exception {parameter = parameter.nestedIfOptional();
        // 所以核心逻辑：读取流、消息换换等都在父类里已经完成。子类直接调用就可以拿到转换后的值 arg 
        // arg 一般都是个类对象。比如 Person 实例
        Object arg = readWithMessageConverters(webRequest, parameter, parameter.getNestedGenericParameterType());
        // 若是 POJO，就是类名首字母小写（并不是形参名）String name = Conventions.getVariableNameForParameter(parameter);

        // 进行数据校验（之前已经详细分析过，此处一笔带过）if (binderFactory != null) {WebDataBinder binder = binderFactory.createBinder(webRequest, arg, name);
            if (arg != null) {validateIfApplicable(binder, parameter);
                if (binder.getBindingResult().hasErrors() && isBindExceptionRequired(binder, parameter)) {throw new MethodArgumentNotValidException(parameter, binder.getBindingResult());
                }
            }

            // 把校验结果放进 Model 里，方便页面里获取
            if (mavContainer != null) {mavContainer.addAttribute(BindingResult.MODEL_KEY_PREFIX + name, binder.getBindingResult());
            }
        }

        // 适配：支持到 Optional 类型的参数
        return adaptArgumentIfNecessary(arg, parameter);
    }
}

HttpEntityMethodProcessor

用于处理 HttpEntity 和RequestEntity类型的入参的。

public class HttpEntityMethodProcessor extends AbstractMessageConverterMethodProcessor {
    @Override
    public boolean supportsParameter(MethodParameter parameter) {return (HttpEntity.class == parameter.getParameterType() || RequestEntity.class == parameter.getParameterType());
    }

    @Override
    @Nullable
    public Object resolveArgument(MethodParameter parameter, @Nullable ModelAndViewContainer mavContainer,
            NativeWebRequest webRequest, @Nullable WebDataBinderFactory binderFactory) throws IOException, HttpMediaTypeNotSupportedException {ServletServerHttpRequest inputMessage = createInputMessage(webRequest);
        // 拿到 HttpEntity 的泛型类型
        Type paramType = getHttpEntityType(parameter);
        if (paramType == null) {
            // 注意：这个泛型类型是必须指定的，必须的
            throw new IllegalArgumentException("HttpEntity parameter'" + parameter.getParameterName() + "'in method" + parameter.getMethod() + "is not parameterized");
        }

        // 调用父类方法拿到 body 的值(把泛型类型传进去了，所以返回的是个实例)
        Object body = readWithMessageConverters(webRequest, parameter, paramType);
        // 注意步操作：new 了一个 RequestEntity 进去，持有实例即可
        if (RequestEntity.class == parameter.getParameterType()) {return new RequestEntity<>(body, inputMessage.getHeaders(), inputMessage.getMethod(), inputMessage.getURI());
        } else { // 用的父类 HttpEntity，那就会丢失掉 Method 等信息（因此建议入参用 RequestEntity 类型，更加强大些）return new HttpEntity<>(body, inputMessage.getHeaders());
        }
    }
}

注意：这里可没有 validate 校验了，这也是经常被面试问到的：使用 HttpEntity 和@RequestBody有什么区别呢？

从代码里可以直观的看到：有了抽象父类后，子类需要做的事情已经很少了，只需要匹配参数类型、做不同的返回而已。
关于它俩的使用案例，此处不用再展示了，因为各位平时工作中都在使用，再熟悉不过了。但针对他俩的使用，我总结出如下几个小细节，供以参考：

@RequestBody/HttpEntity它的参数（泛型）类型允许是 Map
方法上的和类上的 @ResponseBody 都可以被继承，但 @RequestBody 不可以
@RequestBody它自带有 Bean Validation 校验能力（当然需要启用），HttpEntity更加的轻量和方便

HttpEntity/RequestEntity所在包是：org.springframework.http，属于 spring-web
@RequestBody位于org.springframework.web.bind.annotation，同样属于 spring-web

最后还落了一个ErrorsMethodArgumentResolver，在这里补充一下：

ErrorsMethodArgumentResolver

它用于在方法参数可以写 Errors 类型，来拿到数据校验结果。

public class ErrorsMethodArgumentResolver implements HandlerMethodArgumentResolver {
    @Override
    public boolean supportsParameter(MethodParameter parameter) {Class<?> paramType = parameter.getParameterType();
        return Errors.class.isAssignableFrom(paramType);
    }

    @Override
    @Nullable
    public Object resolveArgument(MethodParameter parameter,
            @Nullable ModelAndViewContainer mavContainer, NativeWebRequest webRequest,
            @Nullable WebDataBinderFactory binderFactory) throws Exception {

        Assert.state(mavContainer != null,
                "Errors/BindingResult argument only supported on regular handler methods");

        ModelMap model = mavContainer.getModel();
        String lastKey = CollectionUtils.lastElement(model.keySet());
        
        // 只有 @RequestBody/@RequestPart 注解的  这里面才会有值
        if (lastKey != null && lastKey.startsWith(BindingResult.MODEL_KEY_PREFIX)) {return model.get(lastKey);
        }

        // 简单的说：必须有 @RequestBody/@RequestPart 这注解标注，Errors 参数才有意义
        throw new IllegalStateException(
                "An Errors/BindingResult argument is expected to be declared immediately after" +
                "the model attribute, the @RequestBody or the @RequestPart arguments" +
                "to which they apply:" + parameter.getMethod());
    }
}

到这里，一个不落的把 Spring MVC 内置提供的参数处理器 ArgumentResolver 说了个遍。
前面我有提到过：参数处理对处理器的顺序是敏感的，因此 我们需要关注 Spring MVC 最终的执行顺序 ，这时候我们的聚合容器HandlerMethodArgumentResolverComposite 就出场了：

public class HandlerMethodArgumentResolverComposite implements HandlerMethodArgumentResolver {private final List<HandlerMethodArgumentResolver> argumentResolvers = new LinkedList<>();
    // 具有缓存
    private final Map<MethodParameter, HandlerMethodArgumentResolver> argumentResolverCache = new ConcurrentHashMap<>(256);    
    ...
    // @since 4.3  木有任何地方调用
    public void clear() {this.argumentResolvers.clear();
    }

    // getArgumentResolver()方法是本文的核心
    @Override
    public boolean supportsParameter(MethodParameter parameter) {return getArgumentResolver(parameter) != null;
    }
    @Override
    @Nullable
    public Object resolveArgument(MethodParameter parameter, @Nullable ModelAndViewContainer mavContainer, NativeWebRequest webRequest, @Nullable WebDataBinderFactory binderFactory) throws Exception {
        
        // 这里是关键：每个参数最多只会被一个处理器处理
        HandlerMethodArgumentResolver resolver = getArgumentResolver(parameter);
        if (resolver == null) {throw new IllegalArgumentException("Unsupported parameter type [" + parameter.getParameterType().getName() + "]." + "supportsParameter should be called first.");
        }
        return resolver.resolveArgument(parameter, mavContainer, webRequest, binderFactory);
    }
    
    ...    

    // 这块逻辑保证了每个 parameter 参数最多只会被一个处理器处理
    // 这个从缓存的数据结构中也能够看出来的
    @Nullable
    private HandlerMethodArgumentResolver getArgumentResolver(MethodParameter parameter) {HandlerMethodArgumentResolver result = this.argumentResolverCache.get(parameter);
        if (result == null) {for (HandlerMethodArgumentResolver methodArgumentResolver : this.argumentResolvers) {if (methodArgumentResolver.supportsParameter(parameter)) {
                    result = methodArgumentResolver;
                    this.argumentResolverCache.put(parameter, result);
                    break;
                }
            }
        }
        return result;
    }
}

缺省情况 Spring MVC 注册的处理器（顺序）如下：

它初始化处的代码如下：

RequestMappingHandlerAdapter：@Override
    public void afterPropertiesSet() {
        ...
        // 26 个，详见方法 getDefaultArgumentResolvers
        if (this.argumentResolvers == null) {List<HandlerMethodArgumentResolver> resolvers = getDefaultArgumentResolvers();
            this.argumentResolvers = new HandlerMethodArgumentResolverComposite().addResolvers(resolvers);
        }
        // 12 个  详见方法 getDefaultInitBinderArgumentResolvers
        if (this.initBinderArgumentResolvers == null) {List<HandlerMethodArgumentResolver> resolvers = getDefaultInitBinderArgumentResolvers();
            this.initBinderArgumentResolvers = new HandlerMethodArgumentResolverComposite().addResolvers(resolvers);
        }
        ...
    }

注意：这里面 initBinderArgumentResolvers 最终只会有 12 个处理器，因为它的注册方法如下截图（也是这个顺序）：

前面有提到过说标注有 @InitBInder 注解里也可以写很多类型的参数，但因为它只会有 12 个处理器，所以有些参数它是不能写的（比如 @RequestBody、Errors 等等这种都是不能写的），不用一一枚举，做到心中有数就成。

本文介绍的处理内容，其实还是比较重要的，因为它和消息转换器 HttpMessageConverter 有关，毕竟它是我们目前主流的使用方式，希望可以帮助到大家理解。
这里可以提前预告一下 ：下篇文章将非常重要，因为我将结合实际场景，演示一个我们通过自定义HandlerMethodArgumentResolver 实现的特殊场景的解决方案，非常的优雅和值得推广，有兴趣者可持续关注

ContentNegotiation 内容协商机制(一)—Spring MVC 内置支持的 4 种内容协商方式【享学 Spring MVC】

HandlerMethodArgumentResolver(一)：Controller 方法入参自动封装器（将参数 parameter 解析为值）【享学 Spring MVC】
HandlerMethodArgumentResolver(二)：Map 参数类型和固定参数类型【享学 Spring MVC】
HandlerMethodArgumentResolver(三)：基于 HttpMessageConverter 消息转换器的参数处理器【享学 Spring MVC】

==The last：如果觉得本文对你有帮助，不妨点个赞呗。当然分享到你的朋友圈让更多小伙伴看到也是被 作者本人许可的~==

** 若对技术内容感兴趣可以加入 wx 群交流：Java 高工、架构师 3 群 。
若群二维码失效，请加 wx 号：fsx641385712（或者扫描下方 wx 二维码）。并且备注："java 入群" 字样，会手动邀请入群 **
== 若对 Spring、SpringBoot、MyBatis 等源码分析感兴趣，可加我 wx：fsx641385712，手动邀请你入群一起飞 ==

HandlerMethodArgumentResolver三基于消息转换器的参数处理器享学Spring-MVC

每篇一句

前言

第四类：基于 `ContentType` 消息转换器类型

RequestPartMethodArgumentResolver

AbstractMessageConverterMethodProcessor（重点）

RequestResponseBodyMethodProcessor

HttpEntityMethodProcessor

ErrorsMethodArgumentResolver

Spring MVC 参数处理器的注册与顺序

总结

相关阅读

知识交流

每篇一句

前言

第四类：基于 ContentType 消息转换器类型

RequestPartMethodArgumentResolver

AbstractMessageConverterMethodProcessor（重点）

RequestResponseBodyMethodProcessor

HttpEntityMethodProcessor

ErrorsMethodArgumentResolver

Spring MVC 参数处理器的注册与顺序

总结

相关阅读

知识交流

第四类：基于 `ContentType` 消息转换器类型