2014-10-09 88 views
1

使用Spring,可以使用通过@Configuration注释的类来配置应用程序的各个方面。这些配置类可以直接导入或使用类路径扫描收集。避免对Spring配置类进行类路径扫描

在我看来,类路径扫描尤其对配置类有几个缺点。 一个主要的缺点是,对于多项目(gradle或maven中的子项目),IDE很可能不会同意构建系统上什么时候进入类路径。

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

我们面临的另一个问题是,Spring提供了运行测试工具包,如

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

或者

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

由于这些试验班最终在类路径中,他们也能狡猾地通过检测并用作Spring配置来影响其他测试。

因此,扫描类路径的配置通常很糟糕,或者我们缺少一些明显的缓解措施?

回答

0

到现在为止,我通常使用的类路径扫描谨慎,遵循以下规则:

  • 的配置应仅在同一模块的扫描包
  • 一个configuratino应该只在它自己或子包
  • 扫描

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