使用Docker Compose部署项目时JJWT依赖版本冲突导致应用启动失败

冲突核心原因 #

类路径中同时存在jjwt 0.9.1和jjwt 0.11.2两个版本的同包类，类加载器优先加载了0.9.1版本的SignatureAlgorithm类，而代码运行时调用的是0.11.2版本才新增的getMinKeyLength()方法，最终触发方法不存在的启动报错。

具体修复操作 #

1. 定位老版本依赖的引入链路 #

项目pom.xml中已经注释了jjwt 0.9.1的直接引入配置，证明该包是通过其他组件的传递依赖拉取进来的，执行Maven原生命令扫描全依赖链路：

• 在项目根目录运行 mvn dependency:tree -Dincludes=io.jsonwebtoken:*
• 从输出结果中梳理所有指向jjwt:jar:0.9.1的上游依赖链路，这类依赖常见来源包括旧版权限校验组件、第三方业务starter、安全工具集合包。

2. 全局排除老版本传递依赖 #

对所有会拉取jjwt 0.9.1的上游依赖，在依赖配置的<exclusions>标签中添加排除规则，参考写法：

<dependency>
    <groupId>对应上游依赖的groupid</groupId>
    <artifactId>引入老版本jjwt的组件artifactid</artifactId>
    <exclusions>
        <!-- 排除传递引入的旧版jjwt核心包 -->
        <exclusion>
            <groupId>io.jsonwebtoken</groupId>
            <artifactId>jjwt</artifactId>
        </exclusion>
    </exclusions>
</dependency>

注意：哪怕是嵌套了三四层的间接传递链路，只要最终会引入jjwt 0.9.1，都要在最靠近项目根的上游依赖节点添加排除规则，不要遗漏任意引入链路。

3. 修正Docker构建流程的残留依赖问题 #

当前报错显示镜像内/app/libs目录下同时存在两个版本的jjwt包，说明本地依赖清理完成后，打包流程仍带入了历史残留的老包，需要做三层校验：

• 打包前先执行 mvn clean 清理本地target目录的历史构建产物，避免复用旧的打包残留文件
• 构建镜像时基于干净的基础环境拉取依赖，不要在缓存了旧依赖的环境下直接执行打包命令
• 构建完成后通过临时容器检查镜像内的依赖目录：执行 ls /app/libs/ | grep jjwt，确认目录下仅保留jjwt-api-0.11.2.jar、jjwt-impl-0.11.2.jar、jjwt-jackson-0.11.2.jar三个文件，若仍存在jjwt-0.9.1.jar，删除残留文件后重新构建镜像。

4. 排查类加载优先级异常 #

完成包文件清理后如果仍触发相同报错，逐点核对类加载逻辑：

• 确认项目中启用的自定义类加载器（如热部署组件、插件化框架的隔离加载器）没有将老版本jjwt 0.9.1加载到父类加载层级
• 核对启动参数中的java.class.path配置，确保没有残留指向老版本jar的路径

内容的提问来源于stack exchange，提问作者mohamed amine salah