springboot项目中后端接口不能处理content-type为multipart/form-data类型数据

1.问题现象

   项目中的一类接口(请求类型为POST,且参数接收未用实体封装属性,单参数映射,前段传参content-type采用multipart/form-data)突然无法映射到前台传入的值了,但是本地swagger调用正常调用,并且将本地服务注册到sit的eureka上,路由到本地的请求都能正常接受到前段传参,只有部署在sit环境的服务器处理无法正常处理。

2.问题分析

本地启动的服务时springboot内嵌tomcat服务器启动的,而部署在环境中的web服务容器时jboss,个人猜想和服务器容器的差异有关系,判断可能jboss容器所在的服务器可能出问题了;然而当测试将环境中的代码版本回滚到上个版本时,上述无法处理前段传参的接口恢复正常,可以正确处理前段传参。到此可以基本断定和本次代码变动有关了,于是拉取git提交记录,排查可能引起该问题的变动,发现同事在做 热部署上传功能的时候,因为原有的配置和自己新的功能实现有冲突,就将spring配置文件中的commonMultipartResolver的bean注入实例给注释了,于是赶紧放开注释,问题解决;

3.问题原因

问题解决了之后,思考了一下,阻止自己定位的核心问题还没有理清,为什么本地服务没有受到影响,而环境中的服务就除了问题了呢?自己决定看下源码:

springboot项目中后端接口不能处理content-type为multipart/form-data类型数据_第1张图片

从MultipartAutoConfiguration中可以看出,默认的multipartResolver解析器bean是依赖于servlet容器的,并且在没有MultipartResolver类的情况下注入StandardServletMultipartResolver的实例用来解析处理multipart有关的请求,这也就解释了为eureka路由到本地服务时本地可以正常处理,因为虽然配置文件中的解析器被注释了,但是servlet容器环境下,springboot自动注入了标准的multipart解析器;然而jboss中没有servlet相关jar包,无法启用multipart的自动配置,自然也就没有解析器去处理,需要手动注入。

4.个人感悟

在一个团队中,如果自己对某一项不是特别了解,不要擅自去删除可能你暂时无法理解的代码。如果实在要改动,最好拉上同事,相互评审评估一下,降低引入缺陷的风险,而且在出问题时,同事在帮忙定位时有明确的思路,更快的解决问题

你可能感兴趣的:(问题杂记)