Spring Boot能否嵌套执行应用？嵌套调用run(...)是否可行？

原方案可行性分析 #

你当前在已运行的Spring Boot应用内部通过CompletableFuture启动另一个SpringApplication的方案，并非Spring Boot的常规设计用法，本质上是在同一个JVM进程内嵌套了Spring上下文，这种模式会引发类加载机制冲突——本地IDE能运行是因为IDE的类加载环境是松散的文件目录结构，而打包成JAR后，Spring Boot的类加载器会限制资源查找范围，导致自动配置需要的spring.factories无法被正确定位，这就是你打包后报错的核心原因。该方案从长期维护和稳定性来看，可行性极低，不建议继续使用。

适配场景的简化方案 #

结合你的需求（低复杂度、保持@ConfigurationProperties不可变），推荐以下两种方案：

方案1：抽离测试逻辑为独立服务类，复用/隔离Spring上下文

将原本第三个配置中的测试执行逻辑，封装成独立的服务类，避免启动新的SpringApplication，而是用AnnotationConfigApplicationContext加载测试相关配置，既保证上下文隔离，又规避类加载问题：

// 保持不可变的配置类（构造注入，无Setter）
@ConfigurationProperties(prefix = "test.execution")
public class TestConfigProperties {
    private final String cucumberFeaturesPath;
    private final int parallelThreads;

    // 构造注入，保证不可变
    public TestConfigProperties(String cucumberFeaturesPath, int parallelThreads) {
        this.cucumberFeaturesPath = cucumberFeaturesPath;
        this.parallelThreads = parallelThreads;
    }

    // 仅提供getter
    public String getCucumberFeaturesPath() { return cucumberFeaturesPath; }
    public int getParallelThreads() { return parallelThreads; }
}

// 测试执行服务类
@Service
public class TestExecutionService {
    private final TestConfigProperties testConfig;

    // 构造注入配置，保持不可变
    public TestExecutionService(TestConfigProperties testConfig) {
        this.testConfig = testConfig;
    }

    public CompletableFuture<Void> runTests() {
        return CompletableFuture.runAsync(() -> {
            // 加载测试专属配置上下文，而非启动新SpringApplication
            AnnotationConfigApplicationContext testContext = new AnnotationConfigApplicationContext();
            testContext.register(TestExecutionConfig.class); // 你的第三个配置类
            testContext.refresh();

            // 获取测试执行器并执行
            TestExecutor executor = testContext.getBean(TestExecutor.class);
            executor.runParallelCucumberTests(testConfig);

            // 执行完毕后关闭上下文，释放资源
            testContext.close();
        });
    }
}

// GUI控制器调用服务
@RestController
@RequestMapping("/tests")
public class TestTriggerController {
    private final TestExecutionService testExecutionService;

    public TestTriggerController(TestExecutionService testExecutionService) {
        this.testExecutionService = testExecutionService;
    }

    @PostMapping("/run")
    public ResponseEntity<String> triggerTests() {
        testExecutionService.runTests();
        return ResponseEntity.accepted().body("测试任务已启动");
    }
}

这种方案的核心优势：

• 完全规避嵌套SpringApplication带来的类加载问题
• 配置类通过构造注入保持不可变，符合你的需求
• 测试上下文按需创建和销毁，资源隔离清晰

方案2：测试执行独立进程（极端隔离场景）

如果测试逻辑需要完全独立的JVM环境（比如避免类版本冲突、资源占用隔离），可以将测试执行模块打包成独立的可执行JAR，在GUI控制器中通过ProcessBuilder启动独立进程：

@RestController
@RequestMapping("/tests")
public class TestTriggerController {
    @PostMapping("/run")
    public ResponseEntity<String> triggerTests() {
        CompletableFuture.runAsync(() -> {
            try {
                // 启动独立的测试执行JAR进程
                Process process = new ProcessBuilder(
                        "java", "-jar", "test-execution.jar",
                        "--test.execution.cucumberFeaturesPath=src/test/resources/features",
                        "--test.execution.parallelThreads=4"
                ).start();

                // 可选：捕获进程输出，用于日志或状态反馈
                InputStream inputStream = process.getInputStream();
                // 处理输出逻辑...

                process.waitFor();
            } catch (IOException | InterruptedException e) {
                // 异常处理
                e.printStackTrace();
            }
        });
        return ResponseEntity.accepted().body("测试进程已启动");
    }
}

该方案复杂度稍高，但隔离性最强，CI/CD场景也可直接复用这个独立测试JAR。

关于RequestScoped的补充 #

你提到改用RequestScoped管理生命周期的思路是可行的，但要注意：不要用它来嵌套启动SpringApplication，而是用它来管理单次测试请求的状态（比如当前测试的任务ID、执行进度、结果缓存等），结合方案1的服务类使用，能更好地贴合Spring的生命周期设计。

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