-
Notifications
You must be signed in to change notification settings - Fork 1.1k
INT-2277: Register ChResolver & ErrHandler beans #2805
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
Conversation
Hmmm - no travis for some reason - I checked and all is enabled. I wonder if they suppress a build because there are conflicts? Perhaps rebase and see? |
JIRA: https://jira.spring.io/browse/INT-2277 To avoid extra objects at runtime and reuse a central configuration, register `BeanFactoryChannelResolver` and `MessagePublishingErrorHandler` bean via `DefaultConfiguringBeanFactoryPostProcessor` * Use those beans whenever it is necessary via `IntegrationContextUtils` factory methods against provided `BeanFactory` * To avoid changes in the non-managed test, those new factories fall back to a new instance if there is no an appropriate bean in the `beanFactory`
OK. Now it's back after rebasing. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Cool. Just a couple of questions.
* @param metadataSource the {@link PublisherMetadataSource} to use. | ||
* @deprecated since 5.2 in favor constructor argument. | ||
*/ | ||
@Deprecated |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
See INT-954, not sure if it's still relevant.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Well, I'm not sure what is that tooling, but I guess we have already much more components with similar ctor-based initialization and no one has complained so far.
Therefore I believe we are safe to remove it now.
Well, at least deprecate since it is a mandatory ctor option anyway, but someone may still would like to call a setter. Although that is already not so good to mutate this component at runtime.
/** | ||
* Obtain a {@link DestinationResolver} registered with the | ||
* {@value #CHANNEL_RESOLVER_BEAN_NAME} bean name. | ||
* @param beanFactory BeanFactory for lookup, must not be null. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Assertion?
* {@value #MESSAGE_PUBLISHING_ERROR_HANDLER_BEAN_NAME} bean name. | ||
* By default resolves to the {@link org.springframework.integration.channel.MessagePublishingErrorHandler} | ||
* with the {@value #CHANNEL_RESOLVER_BEAN_NAME} {@link DestinationResolver} bean. | ||
* @param beanFactory BeanFactory for lookup, must not be null. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
ditto
JIRA: https://jira.spring.io/browse/INT-2277
To avoid extra objects at runtime and reuse a central configuration,
register
BeanFactoryChannelResolver
andMessagePublishingErrorHandler
bean via
DefaultConfiguringBeanFactoryPostProcessor
IntegrationContextUtils
factory methods against provided
BeanFactory
back to a new instance if there is no an appropriate bean in the
beanFactory