WIP: ReactorKafka auto-configuration (approach 1) #31258
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.
This is a WIP proposal for ReactorKafka auto-configuration. It is a modification of the original proposal in that it leverages the already existing producer/consumer from KafkaProperties as well as supports property hierarchy of KafkaProperties.
There are still tests that need to be fleshed out but I wanted to get something for us to look at before proceeding.
Commit 1
Has nothing to do w/ ReactorKafka and is strictly a refactor to pull up common properties for re-use. This is leveraged by the 2nd commit but it useful on its own.
Commit 2
Add the ReactorKafka auto-config.
NOTE: I know the "ship has sailed" on this going into 2.7x but I left it here (FOR NOW) as ReactorKafka has not yet made it into the latest Reactor BOM for SB3 (seems to have issues w/ Java17 from 1st glance).
NOTE: This approach inserts the RK props in the KP hierarchy - the same approach used by Admin, Producer, Consumer, and Streams clients.
(+) Behaves like the other Kafka clients do and should be easy for Spring Kafka users to grok
(+) Allows setting producer/consumer at higher level (or not) and sharing (or not) w/ non-reactor clients
(-) The extra layer of overrides (hierarchy) complicates things a bit
@garyrussell I know you advocated for a separate RKP and that would be easy to implement w/ this refactored base properties in commit 1. I do think this approach feels very much like the other clients config props though.
cc: @wilkinsona