关于升级 Dubbo 版本到 2.6.5 后启动失败的“坑”

Posted 2023-04-30

参考技术A Dubbo 从低版本升级到 2.6.5 版本后，启动失败，报错如下：

<b><font color='red'>上终极方案：使用 2.6.2 以下版本或者 2.7.0 以上版本的 dubbo ；</font></b>

具体解决方式需要根据项目的情况解决，提供一些其他方案：

删除 web.xml 中如下的配置：

Spring Boot 工程没有特别好的解决方案，提供两个解决思路：

这个方案也没有绕过添加 web.xml 的命运，做法如下：

观察报错日志，报错位置很明显是 Spring 框架初始化时的报错，重点是： there is already a root application 。

这个错误抛出位置位于： Spring-web 包的 ContextLoader 类的 initWebApplicationContext 方法。

原因很明显， ContextLoader 被调用了至少两遍，第二遍报错导致项目初始化失败，其主要的“罪魁祸首”是 dubbo 包下面的 web-fragment.xml 。

Servlet 3.0 是随着 Java EE 6 规范发布的，主要新增特性：

支持 Servlet 3.0 规范的容器，在启动后会扫描工程的 jar 包，找到符合规范的 添加了相关注解的类 和 web-fragment.xml 然后跟 web.xml 的配置合并作为整个项目的初始化配置。

上述问题的发生原因很明显了:

这个是 Servlet 3.0 提供的一个属性，等同一个开关，设置为 true 则表示 web.xml 已经提供了全部的配置信息，不需要容器再去各个 jar 包找配置了，换句话就是：关闭 可插特性 ；

这个属性是 SpringServletContainerInitializer 注释里面提供的解决思路。这个属性可以理解为指定 web-fragment.xml 的加载顺序，和 ordering 标签的区别是， absolute-ordering 仅仅针对我们指定的 web-fragment.xml 做排序。

轻易升级一个基础框架不是一个好的做法，<b>升级基础框架还是应该关注下当前版本和目标升级版本，框架作者做了些什么事情，出现过什么BUG。</b>

当前的 Spring Boot 的解决方案并不让人满意，毕竟 Spring Boot 的无Xml的感觉还是很爽的，为了这个升级引入了 web.xml 会有一点点不爽。

2.6.5版本的dubbo版本号和RPC通讯版本号变更的细节问题

最近将dubbo从2.6.2升级到了2.6.5，在启动服务的时候发现，在Export服务时，dubbo后面显示的是2.0.2，如下图

明明加载的是2.6.5版本的dubbo，为何这里显示的是2.0.2呢。（通常这个“=”号后面显示的就是dubbo版本号，如在2.6.2版本的dubbo，这里显示的就是dubbo=2.6.2）
翻看dubbo源码，Version.java，对比两个版本可以发现如下变更

在2.6.5版本中，新增了一个常量DEFAULT_DUBBO_PROTOCOL_VERSION，继续看2.6.5版本Version.java代码可以发现，如下

这说明在2.6.2之前，Export的服务时，dubbo=xxx，等于号后面的表示的是dubbo版本号。
而在2.6.2之后，这个xxx(上面的2.0.2)的含义表示的是Dubbo 的RPC 通讯协议的版本