spring-mvc引入jackson-dataformat-xml依赖后部分接口返回xml

工程是一个spring-mvc，使用jackson作为RestController序列化组件，一切都相安无事。直到有一天添加依赖的时候，间接引入了jackson-dataformat-xml，惊奇的发现部分接口的返回竟然从json变成了xml….

带着满脸奔跑的草泥马，不禁提出了3个问题：

1. 为什么原来是好的？
2. 为什么只有部分接口的json变成了xml？
3. 我该怎么解决这个问题？

问题1 为什么原来是好的

既然突然变成了xml，我又没有修改spring序列化相关配置，那么肯定和spring的自动发现有关系了。打开pom准备看看有没有新增的xml相关的组件，果然有一个jackson-dataformat-xml。ok，把这个依赖排除，服务恢复正常。全文完。（老板内心os：给你发工资你就TM那么应付我，下次再出现类似问题怎么搞？）本着不撞南墙心不死，撞完南墙吃狗屎的心态，继续探寻问题的本源…

问题2 为什么只有部分接口的json变成了xml

统计了一下异常接口和正常接口的规律，发现正常接口都是以.json结尾，异常接口没有任何后缀，那么6，给个后缀spring就知道我要返回json？那没理由不给后缀猜不到啊！跟了一下spring的源码，发现spring确实尽力了… 翻开课本org.springframework.web.servlet.mvc.method.annotation.AbstractMessageConverterMethodProcessor那一页，让我们来看第119行至第149行。

唉，那个同学，上课咋不带课本呢，那我投影一下吧，大家看下面的投影：

为什么后缀带.json的接口的没问题呢？因为第121行，由接口后缀推断出了请求的requestedMediaTypes是application/json，而没有任何后缀，只能推断出来都接受(*/*)。

那为什么加上依赖之后就都有问题了呢？因为之前第126行并不包括application/xml，所以无论什么接口，能返回json的都瞎jb返回json。

加上依赖之后，在第137行排序过程中，虽然application/json和application/xml是相等的，但由于这个排序是稳定排序（相等值顺序不变），而且application/xml的记载顺序更先，因此总是选中了application/xml。

问题3 我该怎么解决这个问题呢

spring爸爸早就想好怎么办了，指定一个默认的就成！比如这样

<mvc:annotation-driven content-negotiation-manager="contentNegotiationManager"/> 

<bean id="contentNegotiationManager" 
      class="org.springframework.web.accept.ContentNegotiationManagerFactoryBean"> 
    <property name="defaultContentType" value="application/json" /> 
bean> 

关于更详尽的解决步骤，大家可以参考https://spring.io/blog/2013/05/11/content-negotiation-using-spring-mvc，写的很详细，有什么不懂的去问英语老师吧。