Status

Current state: Under discussion

Discussion thread: here [Change the link from the KIP proposal email archive to your own email thread]

JIRA: 

...

To support this change, have the code that parses the properties ssl.truststore.location and ssl.keystore.location identify values that begin with the string classpath: and pass along the remainder of the value to the ClassLoader's getResource() method.

This means that a value such as conf/truststore.jks would still be interpreted as it is currently being interpreted, whereas classpath:com/example/truststore.jks would be resolved in on the kafka classpath at runtime.

There is a prior example of using classpath: as a prefix in a string to load the resource it refers to in the widely used Spring Framework's Resource concept, which in turn builds on the Uniform Resource Locator design.

To support users that currently store their truststore in a file or directory with a name that begins with classpath: this proposal suggests that another prefix, file:, is introduced for this purpose. Values prefixed with file: are always treated as files, regardless of the presence of an additional classpath: prefix.

...

To make the change completely backwards compatible even for users with surprising filenames, it would be possible to introduce two new configuration keys ssl.truststore.location.resolution.method and ssl.keystore.location.resolution.method that would default to file but could optionally be set to classpath. This suggestion seems undesirable as every new configuration property adds to the cognitive overhead of configuring Apache Kafka. It seems to me like the cost of that additional complexity to avoid a very straight forward migration process of prefixing their path with file: for the extremely rare case of a user with current value that begins with classpath: is not worth the benefit.