[ https://issues.apache.org/jira/browse/KAFKA-16592?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Chia-Ping Tsai resolved KAFKA-16592. ------------------------------------ Fix Version/s: 3.8.0 Resolution: Fixed > 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 > Priority: Major > Labels: clients > Fix For: 3.8.0 > > > 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)