GH-3844: Rework messaging annotation with @Bean #3877
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
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
garyrussell
suggested changes
Aug 22, 2022
|
|
||
| Poller poller = MessagingAnnotationUtils.resolveAttribute(annotations, "poller", Poller.class); | ||
| Reactive reactive = MessagingAnnotationUtils.resolveAttribute(annotations, "reactive", Reactive.class); | ||
| Assert.state(reactive == null || poller == null, "The 'poller' and 'reactive' are mutually exclusive."); |
There was a problem hiding this comment.
Either "'poller' and 'reactive' are mutually exclusive." or "The 'poller' and 'reactive' attributes are mutually exclusive." Also should include the bean name.
| AbstractSimpleMessageHandlerFactoryBean.class) | ||
| && !RouterFactoryBean.class.isAssignableFrom(handlerBeanClass)) { | ||
|
|
||
| applyAdviceChainIfAny(handlerBeanDefinition, annotations); |
There was a problem hiding this comment.
Why are we doing this here - this will add all the advices to the handler - the CEFB (which also gets the full advice chain) selectively applies advices to the handler.
There was a problem hiding this comment.
See the comment exactly in that ConsumerEndpointFactoryBean.adviceChain():
* ARPMHs advise the handleRequestMessage method internally and already have the advice chain injected.
* So we only advise handlers that are not reply-producing.
so, we don't set an adviceChain to the AbstractReplyProducingMessageHandler, neither from XML parser, nor Java DSL - ConsumerEndpointSpec.doGet().
We may revise it though, but I guess there was a reason why you implemented that way in the XML parser day first.
Different issue either way.
| For example, the `SourcePollingChannelAdapter` endpoint for the `consoleSource()` definition <<annotations_on_beans,shown earlier>> gets a bean name of `myFlowConfiguration.consoleSource.inboundChannelAdapter`. | ||
| * The `AbstractEndpoint` bean name is generated with the following pattern: `[@Bean name].[decapitalizedAnnotationClassShortName]`. | ||
| For example, the `SourcePollingChannelAdapter` endpoint for the `consoleSource()` definition <<annotations_on_beans,shown earlier>> gets a bean name of `consoleSource.inboundChannelAdapter`. | ||
| Unlike with POJO methods the bean method name is not included into an endpoint bean name. |
There was a problem hiding this comment.
Suggested change
| Unlike with POJO methods the bean method name is not included into an endpoint bean name. | |
| Unlike with POJO methods, the bean method name is not included in the endpoint bean name. |
garyrussell
approved these changes
Aug 22, 2022
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.
Fixes #3844
MessagingAnnotationPostProcessoras aBeanDefinitionRegistryPostProcessorto process bean definitions as early as possible and register respective messaging
components at that early phase
have bean parsed during AOT building phase
BeanDefinitionPropertiesMapperfor easier mappingof the annotation attributes to the target
BeanDefinition@Bean-related logic from method parsing process@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
@Beanname is based on a method by default, so we end upwith duplicated word in the target endpoint bean name.
Now we don't
configuration.adocrespectively for a new endpoint bean name logicAbstractMethodAnnotationPostProcessoris similar to XML parsers: we feed annotation attributes to the
AbstractStandardMessageHandlerFactoryBeanimpls