记一次类污染问题定位

今天项目线上测试出现了一个问题,一个War包启动失败(使用Jetty Runner启动),报的错是: Caused by: java.lang.NoSuchMethodError: org.apache.cxf.transport.AbstractTransportFactory.<init>(Ljava/util/List;Lorg/apache/cxf/Bus;)V

这个我一看第一反应是肯定是某个依赖的jar包的版本弄错了。我看了一下AbstractTransportFactory这个类,是属于cxf-api里面的(我们用的版本是2.6.2), 于是我就去Jetty解压出来的war包的目录下的lib里面看,发现里面有,cxf-api(2.6.2), cxf-core(3.1.12)等几个jar包,那就奇怪了,cxf-api的版本是对的,我甚至把它解压出来反编译了AbstractTransportFactory类来看,也是没有问题的。百思不得其解。后来同事Jun Gong提醒我说既然它报了那个错,就必定是加载到了错误的class,你这样看是看不出来的,你要把JVM加载的所有的class都打印出来,看最终加载到哪个包里面的类。

Google了一下,我在程序的java启动脚本里面加上了-verbose:class这个参数: java -verbose:class ...... 1 > /tmp/test.log &, 1 > /tmp/test.log是把输出重定位到一个临时文件里面,方便查询。当我查看的时候,居然看到AbstractTransportFactory这个类是从cxf-core(3.1.12)这个包里面加载进来的,就是说cxf-api(2.6.2)和cxf-core(3.1.12)这两个包里面都有FQN(Full Qualified Name)为org.apache.cxf.transport.AbstractTransportFactory的类!!而JVM加载的时候,根据FQN去加载,如果加载到cxf-core里面的,就不会再加载cxf-api里面的,而我们需要的是cxf-api里面的!关键问题是,我们根本没法控制JVM的加载顺序!这就是为什么这个问题之前没有发生,属于概率问题。

虽然最后找到了Root Cause,主要还是我们项目里面各种依赖没有统一和处理好各种依赖关系。但我想吐槽一下,活该cxf这项目半死不活,居然在两个包里面用同一个FQN,这实在是bad practice的典范了。

comments powered by Disqus