[Host.Kafka] Add configurable client builder factories with logging support

[saneks222]

Summary
Enhances the Kafka transport provider by adding a KafkaClientConfig wrapper to the producer and consumer builder factories. This allows custom factories to access both the Confluent client configuration and an ILogger instance, enabling more flexible client.

What's included

• New KafkaClientConfig class — wraps ConfluentConfig (of type T : ClientConfig) and an ILogger to provide full context for builder factories

• Updated factory — ProducerBuilderFactory and ConsumerBuilderFactory now accept KafkaClientConfig and KafkaClientConfig respectively, instead of raw ProducerConfig/ConsumerConfig

• Logger propagation — passes the SMB logger through to custom factories so consumers/producers can be instrumented consistently

• Backward compatibility preserved — default factories continue to work using the ConfluentConfig property internally

• Refactored internal creation — CreateConsumer() and CreateProducerInternal() now construct KafkaClientConfig with the appropriate config and logger

[sonarqubecloud]

Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
100.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud

[zarusz]

@saneks222 you’re definitely on the right track here. Also, to get the DCO gate passing, please follow the sign-off requirement.

I was wondering whether we should go beyond just ILogger and make this a bit more flexible for cases where people need additional dependencies in the factory. For example, we could:

• pass IServiceProvider, allowing additional dependencies to be resolved
• if ProducerBuilder / ConsumerBuilder is registered in MSDI, try resolving it first before falling back to the factory Func

That said, this might not be worth it if it adds too much complexity.

What do you think?

[saneks222]

@saneks222 you’re definitely on the right track here. Also, to get the DCO gate passing, please follow the sign-off requirement.

I was wondering whether we should go beyond just ILogger and make this a bit more flexible for cases where people need additional dependencies in the factory. For example, we could:

• pass IServiceProvider, allowing additional dependencies to be resolved
• if ProducerBuilder / ConsumerBuilder is registered in MSDI, try resolving it first before falling back to the factory Func

That said, this might not be worth it if it adds too much complexity.

What do you think?

I like the idea of passing IServiceProvider - it will give users more flexibility when configuring things. I could pass it into KafkaMessageBusSettings, taking it from MessageBusBuilder.Settings when creating an instance in the WithProviderKafka method. What do you think about this?

Regarding ProducerBuilder / ConsumerBuilder - I didn't see them being registered anywhere in MSDI, so I don't really understand how we could try to resolve them from there.

Regarding the sign-off requirement - the first time I really did commit without a signature, but later I fixed it according to the instructions. The signature is now visible in the commit description. I don't quite understand why the CI/CD is still not happy with this. Maybe I missed something?

[zarusz]

Hey @saneks222 sorry for the late response.

The Sign-Off-Commit has to be of text in all the commits. Your commit does not have it:
e4cbaf7

For example:

Signed-off-by: Joe Smith <joe.smith@email.com>

For the builders, I think I might have mislead they wont be provided in the IServiceProvider, you'd have to pass it into the Func.

Please propose the the changes and I can review.

Thanks,

[saneks222]

Hey @saneks222 sorry for the late response.

The Sign-Off-Commit has to be of text in all the commits. Your commit does not have it: e4cbaf7

For example:

Signed-off-by: Joe Smith <joe.smith@email.com>

For the builders, I think I might have mislead they wont be provided in the IServiceProvider, you'd have to pass it into the Func.

Please propose the the changes and I can review.

Thanks,

After carefully reviewing the situation, I have concluded that there is no need to explicitly pass IServiceProvider — it is already available through MessageBusBuilder when calling AddSlimMessageBus and can be used anywhere in the configuration process. However, this does not resolve the issue of losing scopes and structured data of a specific logger: in KafkaGroupConsumer, the logger is created via loggerFactory.CreateLogger<KafkaGroupConsumer>(), and I believe that this very instance should be provided to the user in ProducerBuilderFactory and ConsumerBuilderFactory.

[sonarqubecloud]

Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
100.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud