Artem Bilan

I don't see a behavior you are describing: ``` @SpringBootApplication public class KafkaGh2302Application { public static void main(String[] args) { SpringApplication.run(KafkaGh2302Application.class, args); } @Bean public NewTopic topic() { return new...

Well, this new `consumerSeekAllowed` feels more like a workaround for what we cannot do right now. And it is a bit awkward: we do `ConsumerSeekAware`, but then `consumerSeekAllowed = false`...

Thanks, Gary! I see the logic in `ListenerConsumer.initialize()`: ``` setupSeeks(); KafkaUtils.setConsumerGroupId(this.consumerGroupId); ``` Which probably has to be swapped to make that `groupId` available for registration.

I'd prefer to have Apache Kafka client-specific native hints exactly in Apache Kafka. Spring does nothing with that reflection around `org.apache.kafka.common.security.authenticator.SaslClientCallbackHandler`, so it is unfair to ask us to fix...

Sounds like a separate implementation and not a mix of concerns for the `@KafkaListener`. May you, please, share as much info on the matter as possible? Maybe some PoC would...

More info is also here: https://github.com/cloudevents/spec/blob/master/kafka-protocol-binding.md

Thank you for sharing your effort, but looks like with upcoming CloudEvents SDK v2 we don't need any custom Producer/Consumer factories: https://github.com/cloudevents/sdk-java/tree/master/kafka. It is only now a matter to specify...

I'm OK with this so far. Curious what @rstoyanchev thinks about this... Thanks

It is. May be next `2.4` version. Anyway I want to share my understanding on the matter. The Spring Kafka and Reactor Kafka is nothing more than wrappers around standard...

This is indeed a bug, but I'm not sure that we can make a breaking change in behavior in the current point version. So, pushing to `Backlog` for future consideration...