追查Spring“不符合自动代理资格”的原因

Question

当您开始使用Spring的自动代理之类的东西时，经常会遇到这种行为，如记录所示：

实现BeanPostProcessor接口的类是特殊的，因此容器对它们的处理方式有所不同。作为ApplicationContext特殊启动阶段的一部分，将在启动时实例化所有BeanPostProcessor及其直接引用的Bean，然后所有这些BeanPostProcessor将以排序的方式进行注册-
并应用于所有其他Bean。由于AOP自动代理是作为BeanPostProcessor本身实现的，因此没有BeanPostProcessor或直接引用的bean都可以进行自动代理（因此不会有“编织”的方面）。

对于任何这样的bean，您应该看到一条信息日志消息：“ Bean’foo’不适合所有BeanPostProcessor处理（例如：不适合自动代理）”。

换句话说，如果我编写了自己的BeanPostProcessor，并且该类直接在上下文中引用了其他Bean，则这些被引用的Bean将不符合自动代理的资格，并且会记录一条消息以达到这种效果。

我的问题是，很难找到直接引用的位置，因为“直接引用”实际上可能是一系列传递依赖关系，最终导致应用程序上下文中的bean数量减少了一半。Spring所提供的只是一条信息消息，除了告诉您何时在此引用网络中捕获了bean之外，并没有什么帮助。

我正在开发的BeanPostProcessor确实具有对其他bean的直接引用，但是它的引用集非常有限。尽管如此，根据日志消息，我上下文中几乎所有的bean都被排除在自动代理之外，但是我看不到这种依赖发生在哪里。

有没有人找到更好的方法来追踪这种情况？

Answer 1

只是为了解决这个问题，未初始化的对象图的崩溃是由于BeanPostProcessor使用@Autowired来获取其依赖关系而导致的，而自动装配机制有效地导致了所有其他bean定义都被初始化，直到我BeanPostProcessor有机会在其中发表意见。物。解决方案是不要对BPP使用自动装配。