...

There are situations where adding configuration options will never be able to satisfy the requirement. For example, the user may need to reuse an existing SSL implementation or share an implementation across multiple applications. For those cases, the the simplest approach would be to support the customization of the SslFactory implementation.

A custom SslFactory implementation might also serve as a stop gap measure when a user needs an SSL feature immediately but the necessary configuration option is not yet available.

Of course it would be easy to simply change the Kafka source code and ship a customized distribution. 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.

Public Interfaces

This KIP will introduce a new interface PluggableSslFactory and a new common configuration option ssl.sslfactory

...

We could still have a default constructor if we add a new method to pass the 3 arguments:
preconfigure(Mode mode, String clientAuthConfigOverride, boolean keystoreVerifiableUsingTruststore);
It would not be possible to call config.getConfiguredInstance() but at least the interface members would document the whole contract. This would work but is not backwards compatible with applications calling SslFactory directlyif we keep the 3-argument constructor for SslFactory and make it call preconfigure().

Another name for preconfigure() could be initialize().

The arguments clientAuthConfigOverride and keystoreVerifiableUsingTruststore seem somewhat arbitrary for a general pluggable interface. They were kept to minimize the changes and maximize backwards compatibility.

...