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

查看:355
本文介绍了追踪Spring的“不符合自动代理条件”的原因的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

当你开始搞乱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将以排序方式注册
- 并应用于
所有其他bean。由于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 l 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 I开发确实有直接引用其他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 来获取其依赖项,并且autowire机制有效地导致在我的 BeanPostProcessor 有机会对此事发表意见。解决方案不是为您的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屋!

查看全文
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆