6

今天,我们在代码中发现了这种模式:

class Foo {
    private List<String> errors;

    public void addError(String error) { ... }
    public List<String> getErrors();
}

虽然代码似乎可以工作,但这是一个单例 Spring bean,它被注入到几个独立的地方,并且 bean 的使用者假设他们每个人都有自己的错误列表。所以这引入了一些微妙的错误。

显而易见的解决方案是教育开发人员避免这种错误,但我想知道是否有静态或运行时代码分析工具可以找到这种错误。

例如,bean 后处理器可以在 bean 返回之前对其进行分析,并查找不是@Autowired.

4

2 回答 2

1

在为此倾注了更多的大脑(我们和其他人)之后,我们想出了这种方法:

  1. 安装一个BeanPostProcessor确保所有单例bean(即bean定义中的范围)在实际bean类型上Singleton具有自定义注释的。@Stateless

    我们选择了自定义注释而不是重用@Singleton,因为我们在其他地方也需要此功能。

    如果注释丢失,工厂会抛出错误。

  2. 在单元测试中,我们使用ClassPathScanningCandidateComponentProvider没有自定义注释来定位类路径上的所有类。然后,我们可以进行复杂而昂贵的测试,以确保 bean 在初始配置后(即自动装配发生后)没有状态发生变化。

如果我们将自动装配的字段移到构造函数中,第二步可能会变得更容易一些,但我们不喜欢需要很多很多参数的方法。如果 Java 或 IDE 可以从 bean 代码生成构建器,那就太好了。由于情况并非如此,我们坚持使用自动装配的字段和/或设置器。

于 2013-08-26T13:02:45.483 回答
0

您可以创建一个 JUnit 测试来加载您的应用程序配置。这可以从这里结合 ListableBeanFactory :

我可以通过扫描spring配置文件中的bean来动态创建一个列表吗?

在这里使用“isSingleton”检查:

如何强制执行 Spring bean 的原型范围

即列出应用程序上下文中的所有bean,然后检查哪些是单例。

这将让您找到所有单例 bean...尽管它不会真正阻止您的错误情况,即有人将这些单例之一视为不是。

于 2013-07-26T14:14:16.217 回答