Defer Messaging annotations process #2769
Merged
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
|
I'll fix test-cases when we agree with the solution. |
|
Please re-push with corrected commit comment |
|
OK. I will. Thanks. |
|
The approach looks good. |
The `AbstractMethodAnnotationPostProcessor` and its implementations have a `beanFactory.getBean()` call for the `@Bean` methods with Messaging annotations. This is done, actually, from the `MessagingAnnotationPostProcessor.postProcessAfterInitialization()` which might be still too early in some scenarios, like Spring Cloud Feign with its child application contexts being initialized from the `FeignClientFactoryBean`, causing a `BeanCurrentlyInCreationException` See https://stackoverflow.com/questions/54887963/beancurrentlyincreationexception-when-using-spring-integration-with-spring-cloud * Implement a `SmartInitializingSingleton` for the `MessagingAnnotationPostProcessor` and gather `Runnable` wrappers for newly introduced `postProcessMethodAndRegisterEndpointIfAny()` to be called later in the `afterSingletonsInstantiated()` when context is still in the initialization phase. All runtime-registered beans are going to be processed normally from the regular `postProcessAfterInitialization()` **Cherry-pick to 5.1.x**
artembilan
force-pushed
the
postpone_annotations_process
branch
from
9ed2b03 to
cfb6cd6
Compare
artembilan
changed the title
|
Re-pushed after rebasing, fixing tests and commit message. |
…andle all the possible `AbstractEndpoint` beans registration. See its JavaDocs for more info * Fix `AbstractCorrelatingMessageHandlerParser` and `AbstractConsumerEndpointParser` to use bean names for `outputChannel` and `discardChannel` instead of bean references. Since `MessagingAnnotationPostProcessor` now registers endpoints and beans for channels much later, than parsers, we can't rely on bean references any more there. * Fixes for failing tests which expected `outputChannel/discardChannel` bean references, when it is already just their names for late binding. * Apply some code style polishing for the affected classes. * Add `@Nullable` for `MessageSelector` parameter in the `QueueChannel.purge()`
|
I think we should not back-port this: too much changes and might be some kind of breaking change for some use-cases... |
Closed
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
The
AbstractMethodAnnotationPostProcessorand its implementationshave a
beanFactory.getBean()call for the@Beanmethods withMessaging annotations.
This is done, actually, from the
MessagingAnnotationPostProcessor.postProcessAfterInitialization()which might be still too early in some scenarios, like Spring Cloud Feign
with its child application contexts being initialized from the
FeignClientFactoryBean, causing aBeanCurrentlyInCreationExceptionSee https://stackoverflow.com/questions/54887963/beancurrentlyincreationexception-when-using-spring-integration-with-spring-cloud
SmartInitializingSingletonfor theMessagingAnnotationPostProcessorand gather
Runnablewrappers for newly introducedpostProcessMethodAndRegisterEndpointIfAny()to be called later in the
afterSingletonsInstantiated()when context isstill in the initialization phase.
All runtime-registered beans are going to be processed normally from the
regular
postProcessAfterInitialization()