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.
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
GH-2226: Add RetryTopicConfigurationSupport #2227
GH-2226: Add RetryTopicConfigurationSupport #2227
Changes from 1 commit
3da9ea9
06979ef
f10f276
58bfaea
c82fa57
39d6549
a887fba
d0f7265
38a58a9
c43f159
dd512b4
File filter
Filter by extension
Conversations
Jump to
There are no files selected for viewing
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.
I don't think this has to be there. Or at least it has to be documented properly:
"For convenience the
@EnableKafkaRetryTopic
is marked also with the@EnableKafka
since former cannot work without secondary"(Or some other proper English language 😄 )
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.
Sure. Now I'm thinking that since Boot's auto configuration already provides an
@EnableKafka
by default, maybe we'd run into the same issue of duplicated beans if users used this@EnableKafkaRetryTopic
annotation?I think that, considering this is a temporary solution until we add this as default in 3.0, maybe it'd be simpler to stick with the
@EnableRetryTopic
annotation, and then either move it to@EnableKafka
or simply kill it and import theSupport
class directly for 3.0. WDYT?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.
No, there is no harm: the
@EnableKafka
does a decent work to not duplicate beans. See its targetKafkaBootstrapConfiguration
.I'm not sure that retry topics should be a default feature.
Therefore keep that
@EnableKafkaRetryTopic
is the way to go from now on.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, if we're introducing a new annotation then, and probably 99% of the users will be using it in a
Spring Boot
application anyway, I'd stick with the simpler@EnableRetryTopic
annotation that should be enough for them, and just add a note in the documentation that if users are not in aSpring Boot
app they should also add@EnableKafka
.But no worries, I'll keep it as is and we can revise this down the road if needed.
Thanks.
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.
Just as a thought, of course we can look into this later, but what if for 3.0 we added this class to
@EnableKafka
, but also added a custom@Condition
that would perform that annotation / bean lookup we had in the other PR, to only add this beans it if there's at least oneRetryTopicConfiguration
or@RetryableTopic
present?This way we'd keep the automatic feature enabling users currently have, while not encumbering other users with this if they don't use it.
Thanks.
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, that's not how other
@Enable...
features work. So, my vote for "No": if you are going to use@RetryableTopic
, then add respective@Enable...
.The condition could be considered in Spring Boot which indeed has some opinion.
The framework by itself has to be as straightforward as possible.
In the end it is just a library with minimal opinion 😉
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.
Sure, makes sense. As you said in another post, eventually it'll be a good thing to better integrate this with
Spring Boot
's auto configuration in the future. But since this approach won't be available forSpring Boot
prior to 3.0, we don't really need to worry about it now.Thanks.
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.
I still want to see some mentioning of this meta-annotation in the Javadocs of this
EnableKafkaRetryTopic
class.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.
Some typo. Or missed renaming...