I guess it could but unless I'm mistaken, you have the same problem as before since it is not pluggable. The idea is you should be able to replace the implementation through configuration, without rebuilding a custom Kafka distribution or resorting to classpath tricks to shadow Kafka classes. I will make that goal explicit in the KIP.
If I could convince Kafka to create my subclass of SslChannelBuilder or SaslChannelBuilder when building a channel, that would get me pretty far for what I'm trying to do. I would simply need to move the call to the SslFactory constructor to its own method so I could override that method to create my own subclass of SslFactory. Please enlighten me if that's already possible while respecting the goal above. I concentrated the solution towards SslFactory since that's what the Jira was asking for. I like the smaller scope of the proposed solution because it solves a problem reported by many people. I am not sure people are clamoring to have a pluggable ChannelBuilder interface. Finally, the proposed solution gets reused twice in SslChannelBuilder and SaslChannelBuilder for that part of the protocol they share. -----Original Message----- From: Harsha [mailto:ka...@harsha.io] Sent: Thursday, October 18, 2018 10:58 AM To: dev@kafka.apache.org Subject: Re: [DISCUSS] KIP-383 Pluggable interface for SSL Factory Hi, Thanks for the KIP. Curious to understand why the ChannelBuilder interface doesn't solve the stated reasons in Motiviation section. Thanks, Harsha On Wed, Oct 17, 2018, at 12:10 PM, Pellerin, Clement wrote: > I would like feedback on this proposal to make it possible to replace > SslFactory with a custom implementation. > https://cwiki.apache.org/confluence/display/KAFKA/KIP-383%3A++Pluggable+interface+for+SSL+Factory >
