New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Provide guidance and better diagnostics when dependency injection makes a bean ineligible for complete post-processing #24092
Comments
Could somebody here elaborate, why it is even possible to eagerly autowire dependencies into the bean-postprocessor. Wouldn't it be better to instantiate bean-postprocessors in another way or to disallow eager dependency instantiation? As far as I can understand this, the chances are high that something won't work as expected if this happens, while i.e. the autoproxying won't be done - the beans are autowirded without the proxy in between. This may result in somthing like the db-transaction missing on method marked as @transactional or even worse - method security not being applied. Or am I wrong? Is this really such an Issue that doesn't deserve more attention? |
I recently found literally thousands of info log messages from @javolek I agree that it would be great if it would be just not possible for people that create their own As long as it's possible to get this wrong, Instead of an option to log at |
Very nice! Thanks, @jhoeller. |
Affects: 5.2 (I believe earlier versions are also affected)
When the dependency relationships between beans causes one or more beans to be ineligible for bean post-processing, info messages are logged:
From what I've seen these messages are often missed or presumed to be unimportant as they're at info level. I wonder if warn level would be more appropriate?
Beyond the level at which the messages are logged, the messages describe the problem but it's difficult to connect them to its cause. In this case, you have to know that AOP relies on proxies, that those proxies are created via a bean post-processor, and that any
Advisor
beans are injected into the post-processor. This chain of events leads to eager initialization of the advisor and its dependencies.I wonder if it would be possible to provide better diagnostics at runtime to explain why a bean is not eligible for bean post-processing? I'd also welcome some additions to the reference documentation that draw attention to the dangers of injecting dependencies into bean post-processors and also highlight where bean post-processing is used and the care that must then be taken when defining beans used by those post-processors.
The text was updated successfully, but these errors were encountered: