GH-4303: Allow @KafkaListener with no topic specification for programmatic resolution#4304
Merged
sobychacko merged 3 commits intoFeb 26, 2026
Conversation
Member
|
Please, ensure DCO requirements. |
ac50b7a to
f15b325
Compare
Contributor
Author
|
@artembilan thanks! Ready for review now |
Contributor
|
@mcebanupgrade Can you add your name as an author to the classes changed? |
sobychacko
requested changes
Feb 25, 2026
|
|
||
| assertThatNoException().isThrownBy(ctx::refresh); | ||
| ctx.close(); | ||
| } |
Contributor
There was a problem hiding this comment.
The test verifies that no exception is thrown, but doesn't assert that the topic was actually resolved programmatically. Consider verifying via KafkaListenerEndpointRegistry that the container's topics contain "programmatically-resolved-topic".
Contributor
Author
There was a problem hiding this comment.
@sobychacko thanks, test updated via b1fd2b0
…ion for programmatic resolution The assertTopic validation introduced in spring-projectsGH-4170 requires exactly one of topics/topicPartitions/topicPattern to be set (count == 1). This breaks use cases where a meta-annotated @KafkaListener intentionally omits all topic specifications because the custom KafkaListenerContainerFactory resolves topics programmatically in createListenerContainer(). Change the validation from count == 1 to count <= 1 so that: - Multiple topic specifications (count > 1) are still rejected - No topic specification (count == 0) is permitted, allowing container factories to resolve topics at runtime Fixes: spring-projects#4303 Signed-off-by: Maxim Ceban <mceban@upgrade.com>
…rt topic creation Signed-off-by: Maxim Ceban <mceban@upgrade.com>
Signed-off-by: Maxim Ceban <mceban@upgrade.com>
e2edef6 to
c99c108
Compare
sobychacko
pushed a commit
that referenced
this pull request
Feb 26, 2026
…ammatic resolution (#4304) Fixes #4303 The `assertTopic` validation introduced in GH-4170 requires exactly one of `topics/topicPartitions/topicPattern` to be set `(count == 1)`. This breaks use cases where a meta-annotated `@KafkaListener` intentionally omits all topic specifications because the custom `KafkaListenerContainerFactory` resolves topics programmatically in `createListenerContainer()`. Change the validation from `count == 1` to `count <= 1` so that: - Multiple topic specifications `(count > 1)` are still rejected - No topic specification `(count == 0)` is permitted, allowing container factories to resolve topics at runtime Update KafkaListenerAnnotationBeanPostProcessorTests to actually assert topic creation **Auto-cherry-pick to `4.0.x` & `3.3.x`** Signed-off-by: Maxim Ceban <mceban@upgrade.com>
spring-builds
pushed a commit
that referenced
this pull request
Feb 26, 2026
…ammatic resolution (#4304) Fixes #4303 The `assertTopic` validation introduced in GH-4170 requires exactly one of `topics/topicPartitions/topicPattern` to be set `(count == 1)`. This breaks use cases where a meta-annotated `@KafkaListener` intentionally omits all topic specifications because the custom `KafkaListenerContainerFactory` resolves topics programmatically in `createListenerContainer()`. Change the validation from `count == 1` to `count <= 1` so that: - Multiple topic specifications `(count > 1)` are still rejected - No topic specification `(count == 0)` is permitted, allowing container factories to resolve topics at runtime Update KafkaListenerAnnotationBeanPostProcessorTests to actually assert topic creation Signed-off-by: Maxim Ceban <mceban@upgrade.com> (cherry picked from commit 87b4393)
Contributor
|
@mcebanupgrade Thanks for the PR! It has been merged upstream and back-ported to the relevant branches (See above for details). |
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
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
3 participants
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.
Summary
The
assertTopicvalidation introduced in GH-4170 / PR #4172 requires exactly one oftopics/topicPartitions/topicPatternto be set (count == 1). This breaks a valid use case where a meta-annotated@KafkaListenerintentionally omits all topic specifications because the customKafkaListenerContainerFactoryresolves topics programmatically increateListenerContainer().This PR changes the validation from
count == 1tocount <= 1so that:count > 1) are still rejected withIllegalStateExceptioncount == 0) is permitted, allowing container factories to resolve topics at runtimeUse Case
A common pattern for custom annotation-driven listeners:
With a custom container factory that resolves topics programmatically:
Before GH-4170, this worked because no validation existed. After GH-4170, the
count == 1check rejectscount == 0, throwing:Changes
KafkaListenerAnnotationBeanPostProcessor.java: ChangedAssert.state(count == 1, ...)toAssert.state(count <= 1, ...)KafkaListenerAnnotationBeanPostProcessorTests.java: Added two tests:shouldRejectMultipleTopicSpecifications— verifies that specifying bothtopicsandtopicPatternstill failsshouldAllowNoTopicSpecificationForProgrammaticResolution— verifies that a meta-annotated@KafkaListenerwith no topics works when a custom container factory resolves topics programmaticallyFixes: #4303