使用Camel读取RabbitMq时Quarkus开发模式报ClassNotFound异常如何解决

Quarkus 开发模式默认采用分层类加载机制，框架依赖类和应用自定义类分别由不同的类加载器实例管理。Camel RabbitMQ 组件默认使用 JDK 原生 ObjectInputStream 做反序列化，该类使用加载 Camel 组件的父类加载器执行类查找，无法识别用户应用中定义的自定义消息类，因此抛出类不存在异常。

你之前在集成测试阶段使用的 quarkus.test.flat-class-path=true 是测试场景下专门拉平类加载层级的配置，该配置默认不作用于开发模式。仅传入 artifactId 配置 parent-first-artifacts 不生效，是因为该配置需要传入完整的 groupId:artifactId 格式才可识别。

• 方案一（最简便，和测试场景解决方案对齐）
  在 application.properties 中添加开发模式平级类加载配置：

  quarkus.dev.flat-class-path=true
  

  该配置会让开发模式和生产、测试场景保持一致的类加载逻辑，直接解决类加载器隔离带来的找不到类问题。

• 方案二（推荐，规避序列化安全风险）
  替换默认的 JDK 原生序列化逻辑，自定义 RabbitMQ 消息转换器，使用 JSON、Protobuf 等更安全的序列化协议：
  你可以直接配置 Camel RabbitMQ 组件使用 Jackson 做消息转换，也可以重写默认转换器的类加载逻辑，指定使用线程上下文类加载器加载目标类：

  // 自定义ObjectInputStream类加载逻辑示例
  public class CustomObjectInputStream extends ObjectInputStream {
      public CustomObjectInputStream(InputStream in) throws IOException {
          super(in);
      }
      @Override
      protected Class<?> resolveClass(ObjectStreamClass desc) throws IOException, ClassNotFoundException {
          return Class.forName(desc.getName(), true, Thread.currentThread().getContextClassLoader());
      }
  }
  

  替换原有反序列化逻辑即可。

• 方案三（保持原有序列化逻辑，修复类加载配置）
  修正 parent-first-artifacts 配置，传入你应用的完整 groupId:artifactId，假设你的应用 GAV 是 com.foo:my-messaging-app:1.0.0，则配置为：

  quarkus.class-loading.parent-first-artifacts=com.foo:my-messaging-app
  

JDK 原生序列化存在原生安全漏洞，生产环境建议优先使用方案二替换序列化协议，避免反序列化攻击风险。

内容的提问来源于stack exchange，提问作者Rui Rodrigues