Make RetryTopicConfigurationSupport initialize RetryTopicComponentFactory lazily #2478
Labels
Milestone
Comments
garyrussell
added
backport 2.9.x (obsolete)
and removed
status: waiting-for-triage
labels
|
Unfortunately, this is not as simple as just making the call to We could, however, detect the existence of a bean of that type in the application context and use that instead of the field. In the meantime, the only work around I can see is to override those 3 bean definitions |
garyrussell
added a commit
to garyrussell/spring-kafka
that referenced
this issue
Nov 14, 2022
Resolves spring-projects#2478 Allow users to define a `RetryTopicComponentFactory` bean for use in infrastructure bean definitions. Previously, although `createComponentFactory()` can be overridden, it is called early in the class lifecycle and can't have any dependencies on Spring beans. Now, if the application context contains a unique bean of this type, it is used instead. **Cannot back port due to breaking API changes; work around for 2.9.x is to override one or more of `destinationTopicResolver`, `kafkaConsumerBackoffManager` and/or `retryTopicConfigurer` bean definition methods.**
garyrussell
added a commit
to garyrussell/spring-kafka
that referenced
this issue
Nov 14, 2022
Resolves spring-projects#2478 Allow users to define a `RetryTopicComponentFactory` bean for use in infrastructure bean definitions. Previously, although `createComponentFactory()` can be overridden, it is called early in the class lifecycle and can't have any dependencies on Spring beans. Now, if the application context contains a unique bean of this type, it is used instead. **Cannot back port due to breaking API changes; work around for 2.9.x is to override one or more of `destinationTopicResolver`, `kafkaConsumerBackoffManager` and/or `retryTopicConfigurer` bean definition methods.**
artembilan
pushed a commit
that referenced
this issue
Nov 14, 2022
Resolves #2478 Allow users to define a `RetryTopicComponentFactory` bean for use in infrastructure bean definitions. Previously, although `createComponentFactory()` can be overridden, it is called early in the class lifecycle and can't have any dependencies on Spring beans. Now, if the application context contains a unique bean of this type, it is used instead. **Cannot back port due to breaking API changes; work around for 2.9.x is to override one or more of `destinationTopicResolver`, `kafkaConsumerBackoffManager` and/or `retryTopicConfigurer` bean definition methods.**
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Expected Behavior
In classes that extend
RetryTopicConfigurationSupportand override the methodcreateComponentFactory(), it should be possible to return an instance of aRetryTopicComponentFactorywhich is itself a bean of the spring context.Current Behavior
Currently, this is not possible, because, in
RetryTopicConfigurationSupport, the methodcreateComponentFactory()is called in the declaration of the attributecomponentFactory. As so, the class that extendsRetryTopicConfigurationSupporthas no time to use a reference from the application context to return. It does not even help to make the subclass to receive the bean in the constructor, as the superclass is initialized first.Context
It has been annoying to find a way to return in the override
createComponentFactory()an instance which is, or which depends on, beans of the context.The text was updated successfully, but these errors were encountered: