Thanks for the questions Matthias!
1. I think we can check the config in the constructor which doesn't take
the client supplier as a parameter. This one:
public KafkaStreams(final Topology topology,
final Properties props) {
...
}
If users provide a client supplier in another constructor, the config won't
be checked and the provided one will be used, which is code would override
the config.
2. I'm fine with `default.client.supplier` and make it the
`DefaultKafkaClientSupplier`
Thanks,
Hao
On Tue, Nov 15, 2022 at 4:11 PM Matthias J. Sax <mj...@apache.org> wrote:
> Thanks for the KIP Hao.
>
> What is the behavior if users set the config and also pass in a client
> supplier into the constructor?
>
> Following other config/API patterns we use, it seems the best thing
> would be if the code would overwrite the config?
>
> If we do this, should we change the config name to
> `default.client.supplier` and not make it `null`, but set the default
> supplier we use currently?
>
> This way, the config and code would behave the same as other configs
> like `default.timestamp.extractor` and similar.
>
>
> -Matthias
>
>
>
> On 11/15/22 3:35 PM, Hao Li wrote:
> > Hi all,
> >
> > I have submitted KIP-884 to add config to configure KafkaClientSupplier
> and
> > would like to start a discussion:
> >
> >
> https://cwiki.apache.org/confluence/display/KAFKA/KIP-884%3A+Add+config+to+configure+KafkaClientSupplier+in+Kafka+Streams
> >
> >
>
--
Thanks,
Hao
