WIP: ReactorKafka auto-configuration (approach 1) #31258
Conversation
spring-projects-issues
added
the
status: waiting-for-triage
| return senderOptions; | ||
| } | ||
|
|
||
| private <T, R> R toInstanceSafe(PropertyMapper.Source<T> source, Function<T, R> target, R defaultOptions) { |
There was a problem hiding this comment.
[UNRELATED] I am going to submit a separate PR to add an API to Source.toInstance that accepts a default instance when the value was filtered.
| security: ... | ||
| properties: ... | ||
|
|
||
| reactor: |
There was a problem hiding this comment.
[TEMPORARY]
This file only exists to illustrate the "full" yaml available.
| Map<String, Object> properties = buildCommonProperties(); | ||
| properties.putAll(this.consumer.buildProperties()); | ||
| public Map<String, Object> buildAdminProperties() { | ||
| // spring.kafka.<common-props> |
There was a problem hiding this comment.
ℹ️ will probably yank these prefix/path comments out later - just easily shows what the mapping is for this proposal review only. It may be helpful to move them up to the method javadoc though in some capacity.
| * @author Chris Bono | ||
| * @since 2.7.0 | ||
| */ | ||
| class KafkaPropertiesBaseWithBootstrapServersAndProducerConsumer extends KafkaPropertiesBaseWithBootstrapServers { |
There was a problem hiding this comment.
ℹ️ This hierarchy is a bit forced and brittle by nature of the config properties method / naming convention. Using inheritance makes the get/set available. Otherwise I would have explored composition.
Hi @snicoll - |
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