Sagar Rao created KAFKA-16592: --------------------------------- Summary: ConfigKey constructor update can break clients using it Key: KAFKA-16592 URL: https://issues.apache.org/jira/browse/KAFKA-16592 Project: Kafka Issue Type: Bug Reporter: Sagar Rao Assignee: Sagar Rao
In [KAFKA-14957|https://issues.apache.org/jira/browse/KAFKA-14957], the constructor of ConfigDef.ConfigKey was updated to add a new argument called {*}alternativeString{*}. As part of the PR, new *define* methods were also added which makes sense. However, since the constructor of *ConfigDef.ConfigKey* itself can be used directly by other clients which import the dependency, this can break all clients who were using the older constructor w/o the *alternativeString* argument. I bumped into this when I was testing the[kafka-connect-redis|[https://github.com/jcustenborder/kafka-connect-redis/tree/master]] connector. It starts up correctly against the official 3.7 release, but fails with the following error when run against a 3.8 snapshot {code:java} Caused by: java.lang.NoSuchMethodError: org.apache.kafka.common.config.ConfigDef$ConfigKey.<init>(Ljava/lang/String;Lorg/apache/kafka/common/config/ConfigDef$Type;Ljava/lang/Object;Lorg/apache/kafka/common/config/ConfigDef$Validator;Lorg/apache/kafka/common/config/ConfigDef$Importance;Ljava/lang/String;Ljava/lang/String;ILorg/apache/kafka/common/config/ConfigDef$Width;Ljava/lang/String;Ljava/util/List;Lorg/apache/kafka/common/config/ConfigDef$Recommender;Z)V at com.github.jcustenborder.kafka.connect.utils.config.ConfigKeyBuilder.build(ConfigKeyBuilder.java:62) at com.github.jcustenborder.kafka.connect.redis.RedisConnectorConfig.config(RedisConnectorConfig.java:133) at com.github.jcustenborder.kafka.connect.redis.RedisSinkConnectorConfig.config(RedisSinkConnectorConfig.java:46) at com.github.jcustenborder.kafka.connect.redis.RedisSinkConnector.config(RedisSinkConnector.java:73) at org.apache.kafka.connect.runtime.AbstractHerder.validateConnectorConfig(AbstractHerder.java:538) at org.apache.kafka.connect.runtime.AbstractHerder.lambda$validateConnectorConfig$3(AbstractHerder.java:412) at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511) at java.util.concurrent.FutureTask.run(FutureTask.java:266) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624) ... 1 more {code} The reason for that is that the connector uses another library called connect-utils which invokes the old constructor [directly|https://github.com/jcustenborder/connect-utils/blob/master/connect-utils/src/main/java/com/github/jcustenborder/kafka/connect/utils/config/ConfigKeyBuilder.java#L62] It is not expected for connector invocations to fail across versions so this would cause confusion. We could argue that why is the constructor being invoked directly instead of using the *define* method, but there might be other clients doing the same. We should add the old constructor back which calls the new one by setting the *alternativeString* to null. -- This message was sent by Atlassian Jira (v8.20.10#820010)