JBoss 10.1.2部署EAR时遇ArchiveException问题求助

看起来你已经做了不少扎实的排查工作了，结合你的信息来看，这个问题的核心是类加载冲突+字节码处理逻辑不兼容导致的，我来帮你拆解根本原因和可行的解决方案：

一、根本原因分析 #

你提到更换com.google.template:soy版本后问题解决，这说明2018-01-03版本的Soy和你的JBoss+Hibernate环境存在兼容性问题，具体可能是以下几点：

• javassist版本隐式冲突：2018-01-03版本的Soy可能依赖了更高版本的javassist（或者内部打包了修改版javassist），虽然Maven依赖树没直接显示，但它可能通过间接传递依赖引入了和Hibernate 5.2.8.Final（依赖3.20.0-GA）、JBoss自带（3.18.1.GA-redhat-2）不兼容的javassist版本，导致Hibernate扫描类文件时无法正确解析ClassFile。
• 字节码操作逻辑冲突：Soy作为模板引擎会用到字节码生成技术，2018-01-03版本可能修改了字节码生成逻辑，生成的类文件格式和Hibernate的扫描器不兼容，触发ArchiveException。
• JBoss模块化类加载优先级问题：JBoss的模块加载器会优先加载自带类库，而EAR中的依赖和Soy的依赖可能在类加载顺序上出现混乱，导致Hibernate拿到的是被Soy修改过的类文件或者不兼容的类版本。

二、可行的解决方案 #

1. 锁定Soy兼容版本（已验证有效） #

继续使用2017-08-08版本的Soy，这个版本和你的JBoss 10.1.2、Hibernate 5.2.8.Final环境兼容，是最直接省心的解决方案。

2. 显式管控javassist版本 #

在你的Mavenpom.xml中通过dependencyManagement强制指定javassist版本为3.20.0-GA（和Hibernate依赖的版本一致），避免任何传递依赖引入不兼容版本：

<dependencyManagement>
    <dependencies>
        <dependency>
            <groupId>org.javassist</groupId>
            <artifactId>javassist</artifactId>
            <version>3.20.0-GA</version>
            <!-- 如果你已经在EAR中打包了javassist，用provided；否则用compile -->
            <scope>provided</scope>
        </dependency>
    </dependencies>
</dependencyManagement>

3. 调整JBoss类加载策略（针对必须用新版Soy的场景） #

如果业务要求必须使用2018-01-03版本的Soy，可以修改JBoss部署配置，让EAR中的javassist优先于JBoss自带模块加载：
在你的EAR根目录下创建jboss-deployment-structure.xml，内容如下：

<jboss-deployment-structure>
    <deployment>
        <!-- 排除JBoss自带的javassist模块，使用EAR中的版本 -->
        <exclusions>
            <module name="org.javassist" />
        </exclusions>
        <!-- 确保EAR中的javassist被优先加载 -->
        <dependencies>
            <module name="deployment.your-ear-name.ear.lib.javassist-3.20.0-GA.jar" export="true" />
        </dependencies>
    </deployment>
</jboss-deployment-structure>

注意替换your-ear-name为你的实际EAR名称，这种方式需要测试是否影响其他应用的类加载。

4. 排查Soy版本的依赖差异 #

对比2017-08-08和2018-01-03版本的Soy依赖树，找出具体变化：

# 查看旧版本依赖
mvn dependency:tree -Dartifact=com.google.template:soy:2017-08-08
# 查看新版本依赖
mvn dependency:tree -Dartifact=com.google.template:soy:2018-01-03

通过对比可以明确新版本是否引入了新的字节码处理库，或者修改了javassist依赖，从而针对性解决冲突。

三、为什么移除org.reflections没用？ #

你移除org.reflections后问题依旧，是因为org.reflections的javassist依赖已经被Maven自动排除（依赖树显示omitted for conflict with 3.20.0-GA），它并不是真正的冲突来源，真正的问题出在Soy的依赖或内部逻辑上。

内容的提问来源于stack exchange，提问作者N.Zukowski