如何让EAR读取WAR中的properties文件？（Wildfly 11、Java 8环境）

这种类加载器的坑我之前在WildFly 11上踩过好几次！单独部署WAR一切正常，但打包成EAR就找不到里面的properties文件，核心问题确实是WildFly中EAR和WAR的类加载策略差异导致的，给你几个亲测有效的解决办法：

1. 修正资源加载方式（最常见的原因） #

单独WAR环境下，你可能用了System.getResourceAsStream()或者不带类加载器的getResourceAsStream()，但EAR里系统类加载器和WAR的专属类加载器不是同一个！

• 换成WAR自身的类加载器来加载资源：

  // 推荐：用当前类的类加载器，保证从WAR的classpath里查找
  InputStream is = this.getClass().getClassLoader().getResourceAsStream("xxx.properties");
  
  // 如果是Servlet类，也可以用ServletContext加载WEB-INF下的资源
  InputStream is = getServletContext().getResourceAsStream("/WEB-INF/classes/xxx.properties");
  

  注意：如果properties放在WEB-INF/classes的子目录里（比如conf文件夹），路径要写成conf/xxx.properties，不要加开头的斜杠。

2. 调整EAR的类加载配置（jboss-app.xml） #

WildFly默认的EAR类加载是父优先，有时候会导致WAR的资源被EAR的类加载器覆盖或者找不到。可以在EAR的META-INF/jboss-app.xml里配置独立的类加载策略：

<jboss-app>
  <!-- 让每个WAR使用独立的类加载器，严格按照模块顺序加载 -->
  <module-order>strict</module-order>
  <loader-repository>
    com.yourcompany:archive=your-ear-name
    <loader-repository-config>java2ParentDelegation=false</loader-repository-config>
  </loader-repository>
</jboss-app>

这个配置会关闭父类加载器优先模式，让WAR优先从自己的classpath查找资源，避免被EAR的类加载器干扰。

3. 确认EAR的打包结构是否正确 #

有时候打包工具（比如Maven、Ant）会把WAR里的资源意外移到EAR根目录，导致WAR内部找不到。检查你的EAR结构是否符合标准：

your-app.ear
├── META-INF/
│   ├── application.xml
│   └── jboss-app.xml（如果配置了的话）
├── your-web.war/
│   ├── WEB-INF/
│   │   ├── classes/
│   │   │   ├── xxx.properties  <!-- 这个文件必须在WAR的classes目录下 -->
│   │   └── web.xml
│   └── ...其他静态资源
└── other-module.jar/

如果用Maven打包，确保WAR模块的pom.xml里资源配置正确，比如：

<build>
  <resources>
    <resource>
      <directory>src/main/resources</directory>
      <includes>
        <include>*.properties</include>
      </includes>
    </resource>
  </resources>
</build>

4. 开启类加载日志调试（排查疑难问题） #

如果以上方法都没用，可以开启WildFly的类加载调试日志，追踪资源的加载路径：
在standalone/configuration/standalone.xml里添加日志配置：

<logger category="org.jboss.as.server.deployment">
  <level name="DEBUG"/>
</logger>
<logger category="org.jboss.classloader">
  <level name="TRACE"/>
</logger>

启动WildFly后，查看日志里的类加载相关输出，就能精准定位到资源找不到的具体原因。

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