记一次升级jenkins2.359引发的项目无法启动的问题

0x00 问题出现

同事私聊我一个文件，并指出测试环境的项目无法启动，测试同事被卡住流程了，需要尽快解决。我拿到文件，看到导致报错的是java.lang.NoClassDefFoundError: Could not initialize class org.hibernate.validator.internal.engine.valueextraction.ValueExtractorManager 。

报错截图.png

0x01 分析

思路一：

看到NoClassDefFoundError，且近期没有对相关代码做处理，那么自然想到的就是包版本不一致导致的类的初始化流程报错。随后就看了pom文件的依赖，发现依赖的特别干净，使用的是org.hibernate.validator:hibernate-validator:6.0.14.Final，没有多版本的歧义。
随后分析ValueExtractorManager的代码，发现代码中涉及到可能会出现问题的地方只有isJavaFxInClasspath()方法，这里埋一个点。不过因为对fx不是很熟，没有继续探究。

ValueExtractorManager静态代码块.png

思路二：

既然代码没有变动，那么是否是服务器环境变动了？想到了之前因为看到jenkins中打开全是小红点，且存在一部分插件无法启动的情况，插件目前的版本都依赖高版本的jenkins，并且插件之间依赖又很多，不想自己一个一个修复，所以打算直接升级jenkins。但是最新版的jenkins（当时是2.3.59）依赖java11的环境。所以在服务器上安装了java11的环境。不想破坏服务器上其他的应用，所以没有配置全局的java11环境，只是启动jenkins使用java11的java_home启动。jenkins启动成功。大体看了一下，没有问题，并且出现异常的插件也确实ok了。
bing了一下，大家都说这个问题可能是没有使用正确的jdk，所以我查看了项目启动命令，确实使用的是1.8的环境。

运行时命令
为了控制变量，目前就使用本地打包上传服务器的方式部署，不通过jenkins打包了。结论是，项目启动正常。这样就基本确认了是打包导致的问题了。

思路三：

明确了是打包的问题以后，且自己安装了高版本jdk的环境后，开始排查jenkins中对maven的配置。
首先试探性的直接在jenkins的workspace中运行mvn命令打包，发现包可以正常启动。更加确认是maven的问题。
随后检查了jenkins中maven的配置，确认了jenkins中使用的是jdk1.8

jenkins参数
检查编译log中的信息，找到了[JENKINS-18403][JENKINS-28294] JDK 'jdk1.8' not supported to run Maven projects.

编译信息

搜索第一个红框中的内容，具体就不多阐述了，直接贴出搜索结果。随后直接在maven的global参数中增加-Dmaven.compiler.release=8参数，增加以后出现Java--Error:java: 无效的标记: -release，没有多想，直接去掉了，其实这个报错恰好说明了是使用的jdk1.8来编译的。
搜索第二框中的内容，了解到了maven的toolchains功能，在maven的conf中本身就有toolchains.xml，修改了该文件

<toolchain>
    <type>jdk</type>
    <provides>
      <version>1.8</version>
      <vendor>openjdk</vendor>
    </provides>
    <configuration>
      <jdkHome>/usr/lib/jvm/java-1.8.0-openjdk-1.8.0.275.b01-0.el7_9.x86_64</jdkHome>
    </configuration>
  </toolchain>

同样在项目中增加了toolchain的插件

<plugin>
    <groupId>org.apache.maven.plugins</groupId>
    <artifactId>maven-toolchains-plugin</artifactId>
    <version>3.1.0</version>
    <executions>
        <execution>
            <goals>
                <goal>toolchain</goal>
            </goals>
        </execution>
    </executions>
    <configuration>
        <toolchains>
            <jdk>
                <version>1.8</version>
                <vendor>openjdk</vendor>
            </jdk>
        </toolchains>
    </configuration>
</plugin>

好，提交，构建！！！🥚🦁️依然无法启动😭。查看日志，发现新的报错Toolchain is ignored，不展开了，有兴趣的同学查看相关的材料，而且加了这个以后，本地编译的时候会告诉你找不到1.8的openjdk，因为没有在本地的toolchains.xml配置。原因是因为jenkins不是直接运行的mvn命令，而是通过java来运行的，这部分看 编译信息 图片的划线处。

/usr/lib/jvm/java-11-openjdk-11.0.15.0.9-2.el7_9.x86_64/bin/java -cp /var/lib/jenkins/plugins/maven-plugin/WEB-INF/lib/maven35-agent-1.13.jar:/usr/share/apache-maven/boot/plexus-classworlds-2.5.2.jar:/usr/share/apache-maven/conf/logging jenkins.maven3.agent.Maven35Main /usr/share/apache-maven/ /var/cache/jenkins/war/WEB-INF/lib/remoting-3028.va_a_436db_35078.jar /var/lib/jenkins/plugins/maven-plugin/WEB-INF/lib/maven35-interceptor-1.13.jar /var/lib/jenkins/plugins/maven-plugin/WEB-INF/lib/maven3-interceptor-commons-1.13.jar 39141

将上面的操作全部恢复😭😭😭

思路四：

辗转反侧，还是打算使用最直接的方式--比对工具，来进行包的比对。用直接mvn打包出来的版本和jenkins构建的版本进行比较。
下图是比对的结果，👈是问题包，👉是正常包

比对结果

图中出现了2中不一致的情况，第一个框标注的是maven打包过程中产生的信息文件，主要是👈的jdk版本和打包时间的不一致。第二个框是问题包多出来的几个jar。回到思路一卡住的地方，似乎发现了一些蹊跷。
随后将本地的jdk版本也换成11，打包，同样出现了这几个包，所以应该是包依赖过程中通过jdk环境做的动态打包。通过idea的MavenHelper插件查询到这几个包是被org.bytedeco:javacv:1.5.3依赖的，随后就排除了这个依赖。

排除依赖
打包，项目启动，It works！🎉

0x02 拓展

刚开始遇到的问题是NoClassDefFoundError，很多同学也不清楚这个error和ClassNotFound之间的差异，这里稍微说一下

ClassNotFound指的是jvm在加载类的过程中，在classpath中没有找到这个类，注意，这里是没有找到。
NoClassDefFoundError指的是jvm找到了这个类，但是在初始化这个类的时候，报错了。虽然日志没有输出具体遇到了什么错误，但是很明确的就是装载类出错了。一般来说就是包冲突引起的，也确实没有想到环境引起的情况。
同样的问题类似NoSuchMethodException，这种也大概率是包冲突引起的
maven打包的时候采用就近原则依赖jar包，不确定的包最好还是显现的排除掉，或者显现的定义好版本。

maven中profile标签的activation可以设置除了jdk外的其他内容，有需要的可以查看官方文档。

0x03 结论

没有想到最后是因为依赖包的问题，另外，maven采用的是3.5.2的版本，不知道在新版本中activation的实现方式是否会关注maven.compiler.source和maven.compiler.targe的内容。
中间走了很多弯路，从思路一方向正确的话可以直接到思路四，中间都是自己摸索的过程。一个简单的问题，可能定位起来会很复杂。看似顺理成章的背后也都是软件对默认配置的一系列规划和思考，通过这种方式摸索其中的来龙去脉，也应该去思考软件开发过程中对各种环境的支持范围，而不是头疼医🧠，脚疼医🦶