-
Notifications
You must be signed in to change notification settings - Fork 1.1k
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
A BeanPostProcessor should not create bean definitions #3844
Comments
I would generally recommend an approach that does not require an individual runtime bean registration per endpoint, e.g. a central endpoint registry bean that accepts every such endpoint (as e.g. in JmsListenerAnnotationBeanPostProcessor). Most importantly, bean definitions are not meant to be registered with an existing instance: A specified bean supplier is meant to create a new instance for every call, or at least perform a fresh lookup for an existing bean instance every time. For the purposes here, it seems you could be using |
It always worked that way and I guess that's just because there is no way in Spring to register several beans at once. All of these looks too noise just for one Just a side note: we also have a What I'm trying to say that registration (and removal) of As a middle ground I can look into a Thank you for your patience! |
Runtime registration and removal of bean definitions isn't going away but unfortunately it is just not ideal for AOT processing, by the very nature of the approach. From my perspective, we should use the opportunity to streamline our registration arrangements for better predictability at build time. The post-processor interfaces always hinted at this by not exposing registry references where they are not meant to be used... but of course downcasts always worked, bypassing that guidance that we had in the SPI design. A Runtime features such as |
Thank you, @jhoeller , for kind explanation! I will look into your suggestions for the next milestone. In addition, I'll investigate if that would be possible to generate some code for those endpoint beans via |
For the record, this was just the trigger that made something totally unrelated to AOT apparent.
I don't know which limitations you're talking about. None of this here has anything to do with AOT. The main purpose of this issue is the registration of bean definitions in a
Please don't. For the first version, we really want the AOT engine to process contexts for various use cases in a generic fashion. Code should be written only for very specific use cases and we should do our best to improve the engine if that's not the case. Thanks! |
No problem, @snicoll ! The code generation is still dark matter for me anyway Then I will look into a |
@jhoeller One benefit of using To help the transition back to registering singletons, perhaps a new API could be provided that also initializes the bean; e.g. <T> T initializeAndAddBean(String name, T instance); Even better if it was available on a top level interface (e.g. |
Another side of this medal is a I don't mind any discussion at any place, but it looks like we are hijacking this issue for other mater, than a concern around bean definition registration in the I'm looking these days into making the mentioned |
Fixes #3844 * Make `MessagingAnnotationPostProcessor` as a `BeanDefinitionRegistryPostProcessor` to process bean definitions as early as possible and register respective messaging components at that early phase * Make bean definitions parsing logic optional for AOT and native mode since beans have bean parsed during AOT building phase * Introduce a `BeanDefinitionPropertiesMapper` for easier mapping of the annotation attributes to the target `BeanDefinition` * Remove `@Bean`-related logic from method parsing process * Change the logic for `@Bean`-based endpoint bean names: since we don't deal with methods on the bean definition phase, then method name does not make sense. It even may mislead if we `@Bean` name is based on a method by default, so we end up with duplicated word in the target endpoint bean name. Now we don't * Fix `configuration.adoc` respectively for a new endpoint bean name logic * In the end the new logic in the `AbstractMethodAnnotationPostProcessor` is similar to XML parsers: we feed annotation attributes to the `AbstractStandardMessageHandlerFactoryBean` impls
Right now,
MessagingBeanPostProcessor
is creating bean definitions. In order to do that, it has to inject theBeanFactory
and downcast it to aBeanRegistry
, seespring-integration/spring-integration-core/src/main/java/org/springframework/integration/config/annotation/MessagingAnnotationPostProcessor.java
Line 233 in 7f631fc
As a side effect of this, we might be able to get rid of that
@Bean
lookup.@Bean
is a configuration class parsing concern and shouldn't be relied upon outside of it.The text was updated successfully, but these errors were encountered: