在JBoss EAP-6.4中读取@PropertySource配置文件失败求助

我之前碰到过类似的问题，核心原因是JBoss EAP和WebSphere对Web应用类路径的处理规则不一样：WebSphere 8.5.5会把Web应用的根目录（也就是你项目里src/main/webapp打包后的根目录）也算进类路径里，但JBoss EAP 6.4严格遵守Servlet规范，只有WEB-INF/classes和WEB-INF/lib这两个目录属于类路径范围。你的git.properties放在src/main/webapp下，打包后会在Web应用根目录，不在JBoss的类路径里，所以Spring用@PropertySource("classpath:git.properties")自然找不到它。

下面给你两种可行的解决办法：

方案1：把文件移到标准类路径目录（强烈推荐） #

这是最符合Spring和Web应用开发规范的做法，几乎不会有兼容性问题：

• 直接把git.properties从src/main/webapp目录移到src/main/resources目录下
• 保持你原有的@PropertySource("classpath:git.properties")注解不动

Maven或Gradle在打包时，会自动把src/main/resources下的所有文件复制到WEB-INF/classes目录里——这个目录是JBoss认可的类路径，Spring就能正常加载配置了，而且WebSphere也完全兼容这种方式，一举两得。

方案2：修改配置适配JBoss（仅当不能移动文件时用） #

如果因为项目限制没法移动文件，那可以修改@PropertySource的路径，直接指向Web应用根目录下的文件。不过这种方式要注意环境差异，维护成本稍高：

方式A：硬编码部署路径（不推荐） #

@Configuration
@ImportResource({"classpath*:META-INF/spring/applicationContext.xml"})
// 替换成你实际的应用部署路径
@PropertySource(value = "file:${jboss.server.base.dir}/deployments/your-app.war/git.properties")
@ComponentScan("com.myapplication.controller")
@EnableWebMvc
@EnableSpringDataWebSupport
public class Config extends WebMvcConfigurerAdapter {
    // 原有代码不变
}

这种方式的问题是，不同环境（测试、生产）的JBoss部署路径可能不一样，需要手动调整，容易出错。

方式B：通过ServletContext动态获取路径（更灵活） #

可以注入ServletContext来动态获取Web应用的根路径，然后加载资源：

@Configuration
@ImportResource({"classpath*:META-INF/spring/applicationContext.xml"})
@ComponentScan("com.myapplication.controller")
@EnableWebMvc
@EnableSpringDataWebSupport
public class Config extends WebMvcConfigurerAdapter {

    @Autowired
    private ServletContext servletContext;

    @Bean
    public PropertySourcesPlaceholderConfigurer propertyConfigurer() {
        PropertySourcesPlaceholderConfigurer configurer = new PropertySourcesPlaceholderConfigurer();
        // 直接获取Web应用根目录下的git.properties
        Resource resource = servletContext.getResource("/git.properties");
        configurer.setLocations(resource);
        return configurer;
    }

    // 原有资源处理器、默认Servlet配置代码不变
}

这种方式不需要硬编码路径，适配性更强，不过需要替换原来的@PropertySource注解，改用代码方式加载配置。

总的来说，优先选方案1，它遵循标准规范，不会引入服务器特定的依赖，后续维护也更省心。

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