Question

我正在编写一个测试用例，它从我的测试资源加载变量并将它们加载到Properties对象中。它检查是否存在一种仅在Docker容器中存在的文件类型，该文件由与Docker容器相关的配置生成。让我明确一点：config.alt.properties目前还没有存在于我的文件系统中，但它曾经和我相信我曾经运行过这些测试。当我在我的eclipse环境中运行时，我通过调试器发现ContextClassLoader凭空提取文件，并使用曾经在该文件中的值加载它，但与正常{{1}不同1}}文件。

config.properties

为什么会这样？更重要的是，如何让ContextClassLoader忘记这个不再存在的文件？这是我的项目结构：

props = new Properties();
try (InputStream altInput = Thread.currentThread().getContextClassLoader().getResourceAsStream("config.alt.properties")) {
        if(altInput != null){
            props.load(altInput);
        }
        else{
            LOG.info("Using environment props file");
            InputStream envInput = Thread.currentThread().getContextClassLoader().getResourceAsStream("config.properties");
            props.load(envInput);
        }
    } catch (IOException e){
        e.printStackTrace();
    }

我尝试使用其他资源加载方法mentioned here，但所有其他方法导致程序根本找不到任何文件，包括src/main/java: {empty} src/main/resources: rebel.xml src/test/java: testClass.Java (where code is from) src/test/resources: config.properties, log4j2.xml。

感谢任何帮助，谢谢。

编辑：测试是使用JUnit运行的，我不知道这是否重要。这是pom.XML中的JUnit信息

在依赖项下：

config.properties

并在dependencyManagement

下

<dependency>
        <groupId>junit</groupId>
        <artifactId>junit</artifactId>
</dependency>

Answer 1

你说文件系统中不存在该文件，但似乎你只在sources目录下查找它。但是在运行时，程序使用mvn clean目录下的资源文件（它们在构建时复制到那里，在默认生命周期的“process-resources”阶段），所以我看到的唯一解释是，快速解决方案是{ {1}}（或使用Eclipse中的“清理项目”功能）。

要验证文件的来源，请在获取文件之前，尝试Thread.currentThread().getContextClassLoader().getResource("‌config.alt.propertie‌s")，记录该值，并验证其指向的位置。

怀疑使用不再存在的文件的Java Context Loader

1 个答案: