追踪Spring“不符合自动代理条件”的原因
当你开始搞砸Spring的自动代理功能时,你经常会遇到这样的行为,如上文所述:
实现 BeanPostProcessor 接口的类是特殊的,因此容器以不同的方式对待它们。所有 BeanPostProcessor 及其直接引用的 Bean 将在启动时实例化,作为 ApplicationContext 特殊启动阶段的一部分,然后所有这些 BeanPostProcessor 都将以排序方式注册 - 并应用于所有后续的 Bean。由于 AOP 自动代理是作为 BeanPostProcessor 本身实现的,因此没有 BeanPostProcessor 或直接引用的 Bean 有资格进行自动代理(因此不会有“编织”到其中的方面。
对于任何此类Bean,您应该看到一条信息日志消息:“Bean 'foo'不符合所有BeanPostProcessors处理的条件(例如:不符合自动代理的条件)”。
换句话说,如果我编写自己的BeanPostProcessor,并且该类直接引用上下文中的其他Bean,那么这些引用的Bean将不符合自动代理的条件,并且会记录一条消息。
我的问题是,追踪直接引用的位置可能非常困难,因为“直接引用”实际上可能是一个传递依赖关系链,最终在应用程序上下文中吸收了一半的bean。Spring给你的只是一条信息信息,除了告诉你一颗豆子何时在这个参考网络中被捕获之外,它并没有太大的帮助。
我正在开发的BeanPostProcessor确实有对其他Bean的直接引用,但它是一组非常有限的引用。尽管如此,根据日志消息,我的上下文中几乎每个bean都被排除在自动代理之外,但我看不到这种依赖关系在哪里发生。
有没有人找到更好的方法来追踪这一点?