追踪 Spring 的“不符合自动代理条件"的原因 [英] Tracking down cause of Spring's "not eligible for auto-proxying"

问题描述

当您开始使用 Spring 的自动代理时，您经常会遇到记录中的这种行为:

When you start messing around with Spring's auto-proxy stuff, you often run into this behaviour as documented:

实现BeanPostProcessor 接口是特别的，所以他们被对待因容器而异.全部BeanPostProcessors 及其直接引用的 bean 将被实例化在启动时，作为特殊启动阶段ApplicationContext，然后所有这些BeanPostProcessors 将被注册以排序的方式 - 并应用于所有进一步的豆.由于 AOP自动代理被实现为BeanPostProcessor 本身，没有BeanPostProcessors 或直接引用的 bean 有资格获得自动代理(因此不会有方面编织"到其中.

Classes that implement the BeanPostProcessor interface are special, and so they are treated differently by the container. All BeanPostProcessors and their directly referenced beans will be instantiated on startup, as part of the special startup phase of the ApplicationContext, then all those BeanPostProcessors will be registered in a sorted fashion - and applied to all further beans. Since AOP auto-proxying is implemented as a BeanPostProcessor itself, no BeanPostProcessors or directly referenced beans are eligible for auto-proxying (and thus will not have aspects 'woven' into them.

对于任何这样的 bean，你应该看到一个信息日志消息:Bean 'foo' 不是有资格得到所有人的处理BeanPostProcessors(例如:不符合自动代理条件)".

For any such bean, you should see an info log message: "Bean 'foo' is not eligible for getting processed by all BeanPostProcessors (for example: not eligible for auto-proxying)".

换句话说，如果我编写自己的 BeanPostProcessor，并且该类直接引用上下文中的其他 bean，那么这些引用的 bean 将不符合自动代理的条件，并且会记录一条消息以实现该效果.

In other words, if I write my own BeanPostProcessor, and that class directly references other beans in the context, then those referenced beans will not be eligible for auto-proxying, and a message is logged to that effect.

我的问题是追踪直接引用的位置可能非常困难，因为直接引用"实际上可能是一个传递依赖链，最终占用了应用程序上下文中的一半 bean.Spring 为您提供的只是一条信息消息，除了告诉您何时在此引用网络中捕获了 bean 之外，它并没有太大帮助.

My problem is that tracking down where that direct reference is can be very difficult, since the "direct reference" can in fact be a chain of transitive dependencies that ends up taking in half the beans in the application context. All Spring gives you is that single info message, and it's not really much help, beyond telling you when a bean has been caught in this web of references.

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

The BeanPostProcessor I'm developing does have direct references to other beans, but it's a very limited set of references. Despite this, pretty much every bean in my context is then being excluded from being auto-proxied, according to the log messages, but I can't see where that dependency is happening.

有没有人找到更好的方法来追踪这个?

Has anyone found a better way of tracking this down?

推荐答案

为了结束这个问题，未初始化对象图的崩溃是由 BeanPostProcessor 使用 @ 引起的Autowired 以获取其依赖项，并且在我的 BeanPostProcessor 有机会对此事发表意见之前，自动装配机制有效地导致所有其他 bean 定义都被初始化.解决方案不是为您的 BPP 使用自动装配.

Just to bring some closure to this question, the collapse of the uninitialized object graph was caused by the BeanPostProcessor using @Autowired to get its dependencies, and the autowire mechanism effectively caused every other bean definition to be initialized before my BeanPostProcessor got a chance to have a say in the matter. The solution is not to use autowiring for your BPPs.

这篇关于追踪 Spring 的“不符合自动代理条件"的原因的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！