[
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)
