个人中心
gpt4 book ai didi

SpringMVC @RequestBody 为null问题的排查及解决

转载 作者：qq735679552 更新时间：2022-09-28 22:32:09 27 4
gpt4 key购买 nike

CFSDN坚持开源创造价值，我们致力于搭建一个资源共享平台，让每一个IT人在这里找到属于你的精彩世界.

这篇CFSDN的博客文章SpringMVC @RequestBody 为null问题的排查及解决由作者收集整理，如果你对这篇文章有兴趣，记得点赞哟.

SpringMVC @RequestBody为null

今天写一个springmvc接口，希望入参为json，然后自动转成自己定义的封装对象，于是有了下面的代码 。

?
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
@PostMapping ( "/update" )
@ApiOperation ( "更新用户信息" )
public CumResponseBody update( @RequestBody UserInfoParam param) {
      int userId = getUserId();
      userService.updateUserInfo(userId, param);
      return ResponseFactory.createSuccessResponse( "ok" );
}
//UserInfoParam.java
public class UserInfoParam {
     private String tel;
     private String email;
     public String getTel() {
         return tel;
     }
     public void setTel(String tel) {
         this .tel = tel;
     }
     public String getEmail() {
         return email;
     }
     public void setEmail(String email) {
         this .email = email;
     }
}

程序正常启动后，使用swaggerUI发起测试 。

?
1
2
3
4
curl -X POST --header 'Content-Type: application/json' --header 'Accept: application/json' -d '{ \
    "email" : "12%40mail.com" , \
    "tel" : "13677682911" \
  } ' ' http: //127.0.0.1:9998/api/user/update'

最后程序报错 。

org.springframework.http.converter.HttpMessageNotReadableException: Required request body is missing: public com.pingguiyuan.shop.common.response.CumResponseBody com.pingguiyuan.shop.weixinapi.controller.UserController.update(com.pingguiyuan.shop.common.param.weixin.UserInfoParam) 。

对了几遍，接口的编写和请求内容都确定没有问题，但是请求的json就是没注入进来转成param对象。查了一圈资料也没找到满意的答案，就只能给springMVC的源码打断点跟一遍，看一下具体是哪里出了问题.

由于本篇不是介绍springMVC实现原理的，就不具体介绍springMVC的源码.

最后断点发现springMVC从request的inputstream没取出内容来(inputstream.read()出来的直接是-1)。由于有在一个拦截器输出请求的参数内容—>【当请求时get时，通过request.getParameterMap();获取参数，当请求时post时，则是直接输出request的inpustream里面的内容】。所以请求的body里面是肯定有内容的,也就是说request.getInputstream()的流是有内容的，那为什么到springMVC这read出来的就是-1呢.

稍微理了下思路，发现是自己给自己挖了个坑。答案是：request的inputstream只能读一次，博主在拦截器中把inputstream的内容都输出来了，到springMVC这，就没有内容可以读了.

关于inputsteam的一些理解

servlet request的inpustream是面向流的，这意味着读取该inputstream时是一个字节一个字节读的，直到整个流的字节全部读回来，这期间没有对这些数据做任何缓存。因此，整个流一旦被读完，是无法再继续读的.

这和nio的处理方式就完全不同，如果是nio的话，数据是先被读取到一块缓存中，然后程序去读取这块缓存的内容，这时候就允许程序重复读取缓存的内容，比如mark()然后reset()或者直接clear()重新读.

特意去看了下InputStream的源码，发现其实是有mark()和reset()方法的，但是默认的实现表示这是不能用的，源码如下 。

?
1
2
3
4
5
6
7
public boolean markSupported() {
     return false ;
}
public synchronized void reset() throws IOException {
         throw new IOException( "mark/reset not supported" );
}
public synchronized void mark( int readlimit) {}

其中mark是一个空函数，reset函数直接抛出异常。同时，inputstream还提供了markSupported()方法，默认是返回false，表示不支持mark，也就是标记（用于重新读）.

但是并不是所有的Inputstream实现都不允许重复读，比如BufferedInputStream就是允许重复读的，从类名来看，就知道这个类其实就是将读出来的数据进行缓存，来达到可以重复读的效果。下面是BufferedInputStream重写的3个方法 。

?
1
2
3
4
5
6
7
8
9
10
11
12
13
public synchronized void mark( int readlimit) {
     marklimit = readlimit;
     markpos = pos;
}
public synchronized void reset() throws IOException {
     getBufIfOpen(); // Cause exception if closed
     if (markpos < 0 )
         throw new IOException( "Resetting to invalid mark" );
     pos = markpos;
}
public boolean markSupported() {
     return true ;
}

可以看到BufferedInputStream的markSupported()方法返回的是true，说明它应该是支持重复读的。我们可以通过mark()和reset()来实现重复读的效果.

@RequestBody 自动映射原理的简单介绍

springMVC在处理请求时，先找到对应controller处理该请求的方法，然后遍历整个方法的所有参数，进行封装。在处理参数的过程中，会调用AbstractMessageConverterMethodArgumentResolver#readWithMessageConverters()类的方法进行进行一些转换操作，源码如下 。

?
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
protected <T> Object readWithMessageConverters(HttpInputMessage inputMessage, MethodParameter parameter,
             Type targetType) throws IOException, HttpMediaTypeNotSupportedException, HttpMessageNotReadableException {
         MediaType contentType;
         boolean noContentType = false ;
         try {
             contentType = inputMessage.getHeaders().getContentType();
         }
         catch (InvalidMediaTypeException ex) {
             throw new HttpMediaTypeNotSupportedException(ex.getMessage());
         }
         if (contentType == null ) {
             noContentType = true ;
             contentType = MediaType.APPLICATION_OCTET_STREAM;
         }
         Class<?> contextClass = parameter.getContainingClass();
         Class<T> targetClass = (targetType instanceof Class ? (Class<T>) targetType : null );
         if (targetClass == null ) {
             ResolvableType resolvableType = ResolvableType.forMethodParameter(parameter);
             targetClass = (Class<T>) resolvableType.resolve();
         }
         HttpMethod httpMethod = (inputMessage instanceof HttpRequest ? ((HttpRequest) inputMessage).getMethod() : null );
         Object body = NO_VALUE;
         EmptyBodyCheckingHttpInputMessage message;
         try {
             message = new EmptyBodyCheckingHttpInputMessage(inputMessage);
             for (HttpMessageConverter<?> converter : this .messageConverters) {
                 Class<HttpMessageConverter<?>> converterType = (Class<HttpMessageConverter<?>>) converter.getClass();
                 GenericHttpMessageConverter<?> genericConverter =
                         (converter instanceof GenericHttpMessageConverter ? (GenericHttpMessageConverter<?>) converter : null );
                 if (genericConverter != null ? genericConverter.canRead(targetType, contextClass, contentType) :
                         (targetClass != null && converter.canRead(targetClass, contentType))) {
                     if (logger.isDebugEnabled()) {
                         logger.debug( "Read [" + targetType + "] as \"" + contentType + "\" with [" + converter + "]" );
                     }
                     if (message.hasBody()) {
                         HttpInputMessage msgToUse =
                                 getAdvice().beforeBodyRead(message, parameter, targetType, converterType);
                         body = (genericConverter != null ? genericConverter.read(targetType, contextClass, msgToUse) :
                                 ((HttpMessageConverter<T>) converter).read(targetClass, msgToUse));
                         body = getAdvice().afterBodyRead(body, msgToUse, parameter, targetType, converterType);
                     }
                     else {
                         body = getAdvice().handleEmptyBody( null , message, parameter, targetType, converterType);
                     }
                     break ;
                 }
             }
         }
         catch (IOException ex) {
             throw new HttpMessageNotReadableException( "I/O error while reading input message" , ex);
         }
         if (body == NO_VALUE) {
             if (httpMethod == null || !SUPPORTED_METHODS.contains(httpMethod) ||
                     (noContentType && !message.hasBody())) {
                 return null ;
             }
             throw new HttpMediaTypeNotSupportedException(contentType, this .allSupportedMediaTypes);
         }
         return body;
     }

上面这段代码主要做的事情大概就是获取请求的contentType，然后遍历配置的HttpMessageConverter—>this.messageConverters，如果该HttpMessageConverter可以用于解析这种contentType(genericConverter.canRead方法)，就用这种HttpMessageConverter解析请求的请求体内容，最后返回具体的对象.

在spring5.0.7版本中，messageConverters默认似乎配置了8种convert。分别是 。

  • ByteArrayMessageConverter
  • StringHttpMessageConverter
  • ResourceHttpMessageConverter
  • ResourceRegionHttpMessageConverter
  • SourceHttpMessageConverter
  • AllEncompassingFormHttpMessageConverter
  • MappingJackson2HttpMessageConverter
  • Jaxb2RootElementHttpMessageConverter

具体的convert是哪些contentType并怎么解析的，这里不多做介绍，感兴趣的朋友可以自行查看源码.

比如我们请求的header中的contentType是application/json，那么在遍历messageConverters的时候，其他genericConverter.canRead()都会返回false，说明没有适配上.

然后遍历到MappingJackson2HttpMessageConverter时genericConverter.canRead()返回true，接着就去获取请求的请求体，并通过json解析成我们@RequestBody定义的对象.

因此，如果我们的请求的contentType和数据协议都是自定义的，我们完全可以自己实现一个HttpMessageConverter，然后解析特定的contentType.

最后记得将这个实现放入messageConverters中，这样springMVC就会自动帮我们把请求内容解析成对象了.

关于@requestBody的一些说明

1、@requestBody注解

常用来处理content-type不是默认的application/x-www-form-urlcoded编码的内容，比如说：application/json或者是application/xml等。一般情况下来说常用其来处理application/json类型.

2、通过@requestBody

可以将请求体中的JSON字符串绑定到相应的bean上，当然也可以将其分别绑定到对应的字符串上.

例如说以下情况:

?
1
2
3
4
5
6
7
8
9
10
$.ajax({　　　　　　　
         　url: "/login" ,　　　　　　　
         　type: "POST" ,　　　　　　　　
           data: '{"userName":"admin","pwd","admin123"}' ,　　　　　　
       　　content-type: "application/json charset=utf-8" ,　　　　　　　　
           success: function (data)
              {　　　　　　　　　　
                 alert( "request success ! " );　　　　　　　
            　}　　　　
});
?
1
2
3
4
@requestMapping ( "/login" )　　　　
   public void login( @requestBody String userName, @requestBody String pwd){　　　　　　
   System.out.println(userName+ " ：" +pwd);　　　　
}

这种情况是将JSON字符串中的两个变量的值分别赋予了两个字符串，但是呢假如我有一个User类，拥有如下字段:

?
1
2
String userName;
String pwd;

那么上述参数可以改为以下形式：@requestBody User user 这种形式会将JSON字符串中的值赋予user中对应的属性上 。

需要注意的是，JSON字符串中的key必须对应user中的属性名，否则是请求不过去的.

3、在一些特殊情况

@requestBody也可以用来处理content-type类型为application/x-www-form-urlcoded的内容，只不过这种方式不是很常用，在处理这类请求的时候，@requestBody会将处理结果放到一个MultiValueMap<String,String>中，这种情况一般在特殊情况下才会使用，例如jQuery easyUI的datagrid请求数据的时候需要使用到这种方式、小型项目只创建一个POJO类的话也可以使用这种接受方式.

以上为个人经验，希望能给大家一个参考，也希望大家多多支持我.

原文链接：https://blog.csdn.net/u013332124/article/details/82630741 。

最后此篇关于SpringMVC @RequestBody 为null问题的排查及解决的文章就讲到这里了,如果你想了解更多关于SpringMVC @RequestBody 为null问题的排查及解决的内容请搜索CFSDN的文章或继续浏览相关文章，希望大家以后支持我的博客！ 。

27 4 0
文章推荐： java中的GC收集器详情
文章推荐： SpringBoot整合阿里云短信服务的方法
文章推荐： java并发之synchronized
文章推荐： JAVA8妙用Optional解决判断Null为空的问题方法
qq735679552
个人简介

我是一名优秀的程序员,十分优秀！

滴滴打车优惠券免费领取
滴滴打车优惠券
全站热门文章
Copyright 2021 - 2024 cfsdn All Rights Reserved 蜀ICP备2022000587号
广告合作:1813099741@qq.com 6ren.com