Java17+Spring Boot3连接Databricks JDBC遇Log4j类转换异常

核心问题结论 #

这些Log4j相关的java.lang.ClassCastException有可能间接引发连接关闭和JobsNotFoundException，但并非直接的因果关系，具体取决于异常触发的时机和驱动内部的错误处理逻辑。

原因拆解 #

1. 类加载冲突根源
   Databricks JDBC驱动2.6.40大概率依赖旧版Log4j组件（比如Log4j 1.x或低版本Log4j2），而你的项目使用的是Log4j2.21.1，再加上Java17的模块化类加载机制、Spark3.5.0自身的日志依赖，多重因素叠加导致ResourceBundleLookup、ContextMapLookup等Lookup类出现类型转换异常——驱动加载的旧版Lookup类和项目引入的新版Log4j核心类不兼容，无法完成类型转换。

2. 对连接与Job的影响路径
   如果这些异常发生在以下场景，就会间接影响连接和Job：

   • 驱动初始化阶段：异常中断日志组件初始化，导致驱动内部流程失败，连接无法正常建立或直接被关闭。
   • 连接运行阶段：执行查询、同步状态等操作时触发日志输出，未捕获的ClassCastException打断驱动内部逻辑，引发连接异常断开。
     一旦连接失效，Spark集群无法接收或响应Job请求，最终就会抛出JobsNotFoundException。

3. 旧环境正常的原因
   Java8的类加载机制更宽松，旧版Simba驱动与当时的Log4j版本兼容性更好，没有跨版本的类冲突问题，因此不会触发这类异常。

解决建议 #

• 排查并排除依赖冲突
  用mvn dependency:tree（Maven）或gradle dependencies（Gradle）生成依赖树，找到Databricks JDBC驱动引入的旧版Log4j依赖，通过<exclusions>（Maven）或exclude（Gradle）标签排除冲突的依赖，强制使用项目的Log4j2.21.1版本。

• 升级Databricks JDBC驱动
  尝试将驱动升级到适配Java17和Log4j2的新版本（如3.x系列），新版本通常会修复这类跨版本兼容性问题，减少类冲突概率。

• 调整日志配置
  检查驱动的日志配置，避免使用过时的Lookup类（ResourceBundleLookup在Log4j2.17+已被标记为不安全）。可以在Log4j2配置文件中禁用这些Lookup，或者将驱动的日志级别调整为ERROR，减少触发异常的日志操作。

• 隔离驱动类加载
  若冲突无法通过依赖排除解决，可利用Spring Boot的类加载隔离机制（如spring-boot-devtools的类隔离功能，或自定义ClassLoader），将Databricks JDBC驱动的类与项目的Log4j类隔离开，避免类加载冲突。

内容的提问来源于stack exchange，提问作者Bhavya Sai Kamasamudram