更新EAR依赖适配新版WildFly：是否需对齐应用内jar版本与模块内置包版本

完全没有强制要求必须把EAR内携带的jar版本调整为和WildFly模块目录的版本一致。WildFly本身的类加载设计就是为了支持应用自带依赖、实现环境隔离，版本选择是可以根据应用自身需求灵活控制的，不存在硬性的对齐规则。

WildFly基于JBoss Modules实现了分层类加载隔离，默认规则非常明确：

• 你的EAR应用作为独立的部署单元，自身lib目录、内部子模块（WAR、EJB-JAR）携带的类，加载优先级永远高于容器内置模块里的类
• 只有当应用自身没有打包对应类时，才会从容器模块目录匹配对应的jar提供给应用

举个最直观的例子：升级后的WildFly最新正式版模块目录里自带了commons-collections4-4.5.jar，但你的EAR里自己打了commons-collections4-4.4.jar，只要你没在部署配置里主动声明依赖WildFly的commons-collections模块，那WildFly根本不会把自己的4.5版本jar加入你的应用类路径，你应用用自己的4.4版本完全可以正常跑，根本不需要为了对齐把自己的版本升到4.5。

虽然没有强制对齐要求，但有几类常见的冲突场景需要针对性处理——注意这些问题本质是类加载隔离不到位，不是必须全版本对齐的理由：

• Jakarta EE规范要求容器统一提供的API类，不适合在EAR内重复打包
  像Servlet API、CDI API、EJB API这类由容器自身实现、要求全局单版本的接口类，如果你在EAR里打了个版本不匹配的jar，会因为“应用类优先”的规则先加载你带的旧版API，和容器的新版本实现类出现二进制兼容问题（典型报错就是NoSuchMethodError、ClassNotFoundException）。这类依赖正确的处理方式是直接从EAR的lib目录移除，统一使用容器提供的版本，而不是无差别对齐所有jar的版本。
• 跨类加载的SPI机制容易出现版本错配
  不少第三方库会通过Java SPI、静态全局注册表等方式跨类加载器获取类实例，比如Commons Collections的工具类、Jackson序列化库的实现类，哪怕你自己EAR里打了对应版本的jar，也可能因为容器类加载器先加载了同包下的类，导致版本不匹配出问题。这种情况只要在jboss-deployment-structure.xml里显式排除对应的容器模块，把类加载路径和容器彻底隔离开就行。
• 旧版本依赖本身的安全问题不能靠“对齐容器版本”解决
  如果你EAR里带的旧版jar存在公开的安全漏洞（比如早年Commons Collections的反序列化RCE漏洞），哪怕能和容器正常兼容跑起来，也必须升级到无漏洞的安全版本——这种调整是为了修复风险，不是为了和容器版本保持一致。

你完全可以不被WildFly内置的jar版本绑定，只要在EAR的META-INF目录下添加jboss-deployment-structure.xml，就能按需定制类加载规则：

• 通过<exclusions>标签显式排除你不想使用的容器内置模块，彻底切断对应jar的类加载路径
• 通过<dependencies>标签显式声明需要依赖的容器模块，指定加载的模块版本
• 通过<sub-deployment>标签定义EAR内部各子模块的类加载层级，避免内部依赖的版本冲突

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