-
Notifications
You must be signed in to change notification settings - Fork 1.1k
Bean ... not elligible for getting processed by all BeanPostProcessors #3945
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
Comments
Let's see how it works for you with really the latest There is no that It would be also great to see some simple project from you to be able to reproduce on our side and determine what is wrong. |
OK. I found the problem with Looking to that |
Yes, that's what I saw during debugging too:
|
Fixes spring-projects#3945 The `IntegrationManagementConfiguration` produces an `IntegrationManagementConfigurer` which is a `BeanPostProcessor`. According to Spring recommendation this kind of infrastructure beans must be declared as `static`. Due to an `implements ImportAware, EnvironmentAware` nature of the `IntegrationManagementConfiguration`, we cannot use `static @Bean` method. But since the `IntegrationManagementConfiguration` is not involved in any bean post-processing, it is safe to follow recommendation and mark it as a `@Role(BeanDefinition.ROLE_INFRASTRUCTURE)`. * Fix `MessagePublishingInterceptor` to initialize `MessagingTemplate` and `DestinationResolver` lazily * Fix `AbstractMethodAnnotationPostProcessor` to initialize `DestinationResolver` lazily **Cherry-pick to `5.5.x`**
Fixes spring-projects#3945 The `IntegrationManagementConfiguration` produces an `IntegrationManagementConfigurer` which is a `BeanPostProcessor`. According to Spring recommendation this kind of infrastructure beans must be declared as `static`. Due to an `implements ImportAware, EnvironmentAware` nature of the `IntegrationManagementConfiguration`, we cannot use `static @Bean` method. But since the `IntegrationManagementConfiguration` is not involved in any bean post-processing, it is safe to follow recommendation and mark it as a `@Role(BeanDefinition.ROLE_INFRASTRUCTURE)`. * Fix `MessagePublishingInterceptor` to initialize `MessagingTemplate` and `DestinationResolver` lazily * Fix `AbstractMethodAnnotationPostProcessor` to initialize `DestinationResolver` lazily **Cherry-pick to `5.5.x`**
* GH-3945: Fix `not eligible for getting processed` Fixes #3945 The `IntegrationManagementConfiguration` produces an `IntegrationManagementConfigurer` which is a `BeanPostProcessor`. According to Spring recommendation this kind of infrastructure beans must be declared as `static`. Due to an `implements ImportAware, EnvironmentAware` nature of the `IntegrationManagementConfiguration`, we cannot use `static @Bean` method. But since the `IntegrationManagementConfiguration` is not involved in any bean post-processing, it is safe to follow recommendation and mark it as a `@Role(BeanDefinition.ROLE_INFRASTRUCTURE)`. * Fix `MessagePublishingInterceptor` to initialize `MessagingTemplate` and `DestinationResolver` lazily * Fix `AbstractMethodAnnotationPostProcessor` to initialize `DestinationResolver` lazily **Cherry-pick to `5.5.x`** * * Use `getChannelResolver()` internally in the `AbstractMethodAnnotationPostProcessor` instead of direct property access which might not be initialized yet * Use a plain `boolean` for `templateInitialized` in the `MessagePublishingInterceptor` to avoid skips in other thread where and move on with still not initialized properties * * Remove unused import * * Fix `this.` prefix for `beanFactory` property reference
* GH-3945: Fix `not eligible for getting processed` Fixes #3945 The `IntegrationManagementConfiguration` produces an `IntegrationManagementConfigurer` which is a `BeanPostProcessor`. According to Spring recommendation this kind of infrastructure beans must be declared as `static`. Due to an `implements ImportAware, EnvironmentAware` nature of the `IntegrationManagementConfiguration`, we cannot use `static @Bean` method. But since the `IntegrationManagementConfiguration` is not involved in any bean post-processing, it is safe to follow recommendation and mark it as a `@Role(BeanDefinition.ROLE_INFRASTRUCTURE)`. * Fix `MessagePublishingInterceptor` to initialize `MessagingTemplate` and `DestinationResolver` lazily * Fix `AbstractMethodAnnotationPostProcessor` to initialize `DestinationResolver` lazily **Cherry-pick to `5.5.x`** * Use `getChannelResolver()` internally in the `AbstractMethodAnnotationPostProcessor` instead of direct property access which might not be initialized yet * Use a plain `boolean` for `templateInitialized` in the `MessagePublishingInterceptor` to avoid skips in other thread where and move on with still not initialized properties * Remove unused import * Fix `this.` prefix for `beanFactory` property reference # Conflicts: # spring-integration-core/src/main/java/org/springframework/integration/config/annotation/AbstractMethodAnnotationPostProcessor.java
Wow that was quick. Thanks for this 🙂👍 |
Uh oh!
There was an error while loading. Please reload this page.
In what version(s) of Spring Integration are you seeing this issue?
5.3.13
Describe the bug
During startup of my Spring Integration application, the following three messages appear:
Expected behavior
All beans are created without warning.
Details
I undestand this is due to cyclic dependencies between beans. I get that these are informational messages, and that the beans in question likely don't need to be post-processed, but they are still bothersome.
Is there anything I can do in my application to avoid these messages? Or if not, could this be fixed in Spring Integration?
The text was updated successfully, but these errors were encountered: