Quarkus扩展静态配置引发ClassCastException问题咨询

问题背景 #

我们维护一个面向业务流程自动化的Java六边形架构框架，原仅支持Spring Boot集成，目前正在开发Quarkus扩展：

• 主扩展负责通用核心逻辑，依赖vanillabp命名空间下的default-adapter配置属性
• 适配器扩展实现六边形架构的适配器组件，使用同一vanillabp命名空间下adapters节点内的专属配置
• 主扩展需要映射整个vanillabp命名空间的配置，但部分属性仅适配器扩展知晓，导致配置加载失败
• 为保留这种混合配置风格，尝试通过StaticInitConfigBuilderBuildItem结合ConfigBuilderFactory忽略未映射属性，却触发ClassCastException——根源是io.quarkus.runtime.configuration.ConfigBuilder由QuarkusClassLoader加载，类加载上下文不匹配

解决方案验证 #

将MigrationAdapterPropertiesBuilder移至runtime模块后，所有测试均通过，配置加载正常。

原因解析 #

Quarkus采用部署时与运行时分离的类加载机制，对应两个隔离的类加载器：

• 部署时类加载器：负责处理扩展构建阶段的逻辑（如@BuildStep注解的代码），加载Quarkus构建API相关类（包括ConfigBuilder）
• 运行时类加载器：负责加载应用运行阶段的业务代码与运行时API类，与部署时类加载器相互隔离

之前将MigrationAdapterPropertiesBuilder放在deployment模块（部署阶段代码），它所依赖的ConfigBuilder由部署时类加载器加载；而StaticInitConfigBuilderBuildItem的逻辑最终会在运行时类加载器上下文执行，跨类加载器的类型转换必然失败，抛出ClassCastException。

将配置构建类移至runtime模块后，它会被运行时类加载器加载，与ConfigBuilder处于同一类加载上下文，类型匹配问题自然解决。

结论 #

将MigrationAdapterPropertiesBuilder移至runtime模块的做法完全正确，符合Quarkus扩展开发的类加载隔离规范，是解决此类跨类加载器类型转换问题的标准方案。

内容的提问来源于stack exchange，提问作者Stephan Pelikan