Question

使用Spring，可以使用带有@Configuration注释的类来配置应用程序的各个方面。可以直接导入这些配置类，也可以使用类路径扫描收集这些配置类。

在我看来，类路径扫描特别对于配置类有几个缺点。一个主要的缺点是，对于多项目（gradle或maven中的子项目），IDE很容易不同意构建系统在什么时候进入类路径。

特别是在我目前的情况下，gradle将为每个子项目隔离类路径测试资源（src / main / test中的文件），这意味着一个子项目中的测试不会通过类路径扫描从其他子项目测试中找到Spring类（除非指定这个）。然而，IntelliJ（13.1.4）没有进行这种隔离，导致测试结果在gradle和IntelliJ中有所不同。这可以在任何时候重新出现（新的intelliJ或Eclipse版本），而像其他任何错误一样，这是一个主要的烦恼。

我们遇到的另一个问题是Spring提供了一个运行测试的工具包，例如

@RunWith(SpringJUnit4ClassRunner.class)
@WebAppConfiguration
public class FooTest {...}

或者

@RunWith(SpringJUnit4ClassRunner.class)
@ContextConfiguration
public class FooTest {...}

由于这些Test类最终会出现在类路径上，因此它们也可以通过检测并用作Spring配置来狡猾地影响其他测试。

扫描类路径以获取配置通常是不好的，还是我们错过了一些明显的缓解措施？

Answer 1

到目前为止，我通常会谨慎地使用类路径扫描，遵循以下规则：

配置应该只扫描同一模块中的包
configuratino应该只扫描它自己或子包

另外，使用@Import定位另一个配置似乎要好得多。它使意图和依赖更加明确，并有助于避免类路径问题。

避免对Spring Configuration类进行类路径扫描

1 个答案: