最近在搭建一个Spring cloud架构。
微服务下采用的是轻量级的ssm框架。在写mybatis的mapper.xml文件时,出现了一个bug。
<select id="loginNode" resultType="tern.block.core.dto.Node" parameterType="map">
select * from node_info where node_email=#{loginEmail}
</select>
这个对象tern.block.core.dto.Node 的代码如下
public class Node implements Serializable{
........
}
如果给这个对象加入自定义构造器,(业务需求) ,那么他的默认构造器就会不起作用。此时,ssm框架正常运行,bean对象可以正常获取。若是,你使用默认构造器,或者自定义一个空构造器。就会出现,明明查询语句都正常,但是从数据库内却获取出一个null对象。这是由于mapper.xml文件在匹配对象的时候,会自动优先匹配空构造器,导致注入了一个null对象。
这种情况,只要自定义一个非空构造器,且把空构造器删去,即可获取到对象实例。
但是,现在spring cloud 微服务下需求消息中间件。这里使用的是rabbitmq 。rabiitmq 消费者在解析对象时,会判断此对象的默认构造器。即要解析的对象,必须实现一个空构造器,不然无法正常解析json后的对象。
这种情况也很好解决,直接向对象内添加一个空构造器即可。
重点来了,现在ssm和rabbitmq需要对同一个对象进行操作。那么以上解法就是矛盾的。ssm不需要对象的空构造,而rabbitmq却必须要求一个默认构造器,这样就会出现,使用的了rabbitmq却无法正常获取到bean对象。有一部分功能无法正常使用。
这个bug现在还未想到特别有效的解决方法。在部署测试环境的时候,肯定会出现问题。
在开发环境下的解决方案及,先把默认构造器及空构造器添加上去,然后启动需要默认构造器的微服务,然后再把默认构造器删掉,再去启动ssm框架下的微服务。这是个错开效果的解决方案,即更改服务启动顺序。
这里仅记录一个bug。方便以后排查。