Wildfly全局库实例化部署类触发ClassNotFoundException问题咨询

问题根因 #

Wildfly采用模块化层级隔离的类加载机制，全局库无论是放置在公共lib目录还是定义为静态全局module，其对应的类加载器都处于公共层级，优先级高于各独立部署EAR/WAR应用的专属类加载器。按照默认双亲委派规则，上层类加载器无权访问下层类加载器管辖路径下的类，这就是全局库使用自身类加载器实例化应用内扩展类时抛出ClassNotFoundException的核心原因。

可行解决方案 #

不需要一上来就实现自定义类加载器，按改造成本从低到高可选择以下方案：

• 线程上下文类加载器方案（推荐，零额外配置，代码改动极小）
  这是Jakarta EE/Java EE环境下上层公共类库加载下层应用实现类的标准实践，完全符合Wildfly类加载规范：
  1. 调整全局库的扩展类实例化时机，别在全局库自身初始化、容器启动阶段就执行类加载逻辑，把实例化动作延后到应用侧主动调用全局库初始化接口的节点
  2. 应用侧调用全局库初始化接口传入扩展类名时，同时传入当前线程上下文类加载器：Thread.currentThread().getContextClassLoader()，这个类加载器就是当前部署应用的专属类加载器，能直接访问应用内所有类资源
  3. 全局库侧实例化扩展类时，别用默认的Class.forName(类名)方法——这个方法默认会用调用方也就是全局库自身的类加载器，改用三参数的重载方法：Class.forName(传入的类名, true, 传入的上下文类加载器)，之后正常完成实例化即可。
     这个方案是Spring、SLF4J等绝大多数通用框架在应用服务器环境下加载自定义扩展的通用实现，没有类冲突风险，兼容性最好。
• 类加载导出导入配置方案
  如果全局库是通过jboss-deployment-structure.xml配置为全局部署依赖的（而非静态module），可以在每个独立应用的部署配置文件中声明将自定义扩展类所在包导出为可被全局依赖访问的资源，同时在全局库的配置中声明对各应用导出包的依赖。这个方案缺陷很明显：每个应用部署时都要单独加配置，多应用部署时如果出现同包名同类名的扩展类会直接触发类冲突，灵活性很差，只适合固定少量应用的场景。
• 自定义类加载器方案（非必要不推荐）
  仅当完全改不动全局库现有实例化逻辑、也没法调整类加载触发时机的时候，才需要考虑自定义类加载器实现。实现时必须把各应用的专属类加载器设为自定义类加载器的优先委派目标，别随便打破Wildfly原有的类加载隔离规则，不然很容易出类链接错误、类加载器内存泄漏这类排查成本极高的问题。

内容的提问来源于stack exchange，提问作者Kevin Schroeder