Skip to content

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

Closed
sebastianhaberey opened this issue Nov 15, 2022 · 4 comments · Fixed by #3947
Closed

Bean ... not elligible for getting processed by all BeanPostProcessors #3945

sebastianhaberey opened this issue Nov 15, 2022 · 4 comments · Fixed by #3947

Comments

@sebastianhaberey
Copy link

sebastianhaberey commented Nov 15, 2022

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:

2022-11-15 08:21:40.518 INFO 85755 --- [           main] trationDelegate$BeanPostProcessorChecker : Bean 'integrationChannelResolver' of type [org.springframework.integration.support.channel.BeanFactoryChannelResolver] is not eligible for getting processed by all BeanPostProcessors (for example: not eligible for auto-proxying)
2022-11-15 08:21:40.521 INFO 85755 --- [           main] trationDelegate$BeanPostProcessorChecker : Bean 'integrationDisposableAutoCreatedBeans' of type [org.springframework.integration.config.annotation.Disposables] is not eligible for getting processed by all BeanPostProcessors (for example: not eligible for auto-proxying)
2022-11-15 08:21:40.538 INFO 85755 --- [           main] trationDelegate$BeanPostProcessorChecker : Bean 'org.springframework.integration.config.IntegrationManagementConfiguration' of type [org.springframework.integration.config.IntegrationManagementConfiguration] is not eligible for getting processed by all BeanPostProcessors (for example: not eligible for auto-proxying)

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?

@sebastianhaberey sebastianhaberey added status: waiting-for-triage The issue need to be evaluated and its future decided type: bug labels Nov 15, 2022
@artembilan
Copy link
Member

Let's see how it works for you with really the latest 5.5.15 version: https://spring.io/projects/spring-integration#learn!

There is no that org.springframework.integration.config.annotation.Disposables any more.

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.

@artembilan artembilan added this to the 6.0.0 milestone Nov 15, 2022
@artembilan artembilan added in: core backport 5.5.x and removed status: waiting-for-triage The issue need to be evaluated and its future decided labels Nov 15, 2022
@artembilan
Copy link
Member

OK. I found the problem with IntegrationManagementConfiguration.
It does produce 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).

Looking to that BeanFactoryChannelResolver next...

@sebastianhaberey
Copy link
Author

sebastianhaberey commented Nov 15, 2022

Yes, that's what I saw during debugging too:

Bean [type] depending on BeanPostProcessor [type]
1 integrationChannelResolver [BeanFactoryChannelResolver] internalMessagingAnnotationPostProcessor [BeanPostProcessor]
2 integrationDisposableAutoCreatedBeans [Disposables] internalMessagingAnnotationPostProcessor [BeanPostProcessor]
3 IntegrationManagementConfiguration [IntegrationManagementConfiguration] integrationManagementConfigurer [BeanPostProcessor]

artembilan added a commit to artembilan/spring-integration that referenced this issue Nov 15, 2022
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`**
artembilan added a commit to artembilan/spring-integration that referenced this issue Nov 15, 2022
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`**
garyrussell pushed a commit that referenced this issue Nov 15, 2022
* 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
artembilan added a commit that referenced this issue Nov 15, 2022
* 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
@sebastianhaberey
Copy link
Author

Wow that was quick. Thanks for this 🙂👍

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants