[jira] [Commented] (KAFKA-8407) Connector client overrides broken on client configs with type 'Class' or 'List'

["ASF GitHub Bot (JIRA)" <ji...@apache.org>]

    [ https://issues.apache.org/jira/browse/KAFKA-8407?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16846152#comment-16846152 ] 

ASF GitHub Bot commented on KAFKA-8407:
---------------------------------------

C0urante commented on pull request #6789: KAFKA-8407: Fix validation of class and list configs in connector client overrides
URL: https://github.com/apache/kafka/pull/6789
 
 
   [Jira](https://issues.apache.org/jira/browse/KAFKA-8407)
   
   Because of how config values are converted into strings in the `AbstractHerder.validateClientOverrides()` method after being validated by the client override policy, an exception is thrown if the value returned by the policy isn't already parsed as the type expected by the client `ConfigDef`. A more thorough writeup of how this happens is available in the linked Jira ticket.
   
   The fix here involves parsing client override properties before passing them to the override policy.
   
   A unit test is added to ensure that several different types of configs are validated properly by the herder.
   
   This bug fix should be included in the recently-cut 2.3 branch.
   
   ### Committer Checklist (excluded from commit message)
   - [ ] Verify design and implementation 
   - [ ] Verify test coverage and CI build status
   - [ ] Verify documentation (including upgrade notes)
   
 
----------------------------------------------------------------
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
users@infra.apache.org


> Connector client overrides broken on client configs with type 'Class' or 'List'
> -------------------------------------------------------------------------------
>
>                 Key: KAFKA-8407
>                 URL: https://issues.apache.org/jira/browse/KAFKA-8407
>             Project: Kafka
>          Issue Type: Bug
>          Components: KafkaConnect
>    Affects Versions: 2.3.0
>            Reporter: Chris Egerton
>            Assignee: Chris Egerton
>            Priority: Blocker
>              Labels: connect
>
> When a connector request is submitted that overrides a client configuration that is meant to contain the name of a class (such as {{sasl.login.callback.handler.class}}), a 500 response is generated and the following stack trace can be found in the logs for Connect:
>  
> {quote}[2019-05-22 14:51:36,123] ERROR Uncaught exception in REST call to /connectors (org.apache.kafka.connect.runtime.rest.errors.ConnectExceptionMapper:61)
> java.lang.ClassCastException: java.lang.String cannot be cast to java.lang.Class
> at org.apache.kafka.common.config.ConfigDef.convertToString(ConfigDef.java:774)
> at org.apache.kafka.connect.runtime.AbstractHerder.convertConfigValue(AbstractHerder.java:491)
> at org.apache.kafka.connect.runtime.AbstractHerder.validateClientOverrides(AbstractHerder.java:426)
> at org.apache.kafka.connect.runtime.AbstractHerder.validateConnectorConfig(AbstractHerder.java:342)
> at org.apache.kafka.connect.runtime.distributed.DistributedHerder$6.call(DistributedHerder.java:565)
> at org.apache.kafka.connect.runtime.distributed.DistributedHerder$6.call(DistributedHerder.java:562)
> at org.apache.kafka.connect.runtime.distributed.DistributedHerder.tick(DistributedHerder.java:292)
> at org.apache.kafka.connect.runtime.distributed.DistributedHerder.run(DistributedHerder.java:241)
> 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)
> at java.lang.Thread.run(Thread.java:748)
> {quote}
> This appears to be limited only to client configs that are meant to be classes or lists due to the fact that {{ConfigDef.convertToString(...)}} assumes its first argument is an instance of {{Class<?>}} when its second argument is {{ConfigDef.Type.CLASS}} and then casts accordingly, and acts similarly for lists. If the second argument is anything else, {{toString()}} is invoked on it without any casting, avoiding any problems.
>  
> The cause of this is due to the fact that the newly-introduced {{ConnectorClientConfigOverridePolicy}} interface returns a list of {{ConfigValue}} instances for its validation. The {{value()}} for each of these can be any type, although with the default implementations available ({{All}}, {{None}}, {{Principal}}) if one is returned at all it's just the same type of what was passed in for that particular config. In the case of the {{AbstractHerder.validateClientOverrides(...)}} method, the raw strings for the client configs are used. However, the {{AbstractHerder.convertConfigValue(...)}} is then called for those raw strings but with the {{ConfigDef.Type}} of the config based on the relevant client {{ConfigDef}} (i.e., {{ProducerConfig.configDef()}}, {{ConsumerConfig.configDef()}}, or {{AdminClientConfig.configDef()}}). This in turn can and will result in {{ConfigDef.convertToString(someClassNameAsAString, ConfigDef.Type.CLASS)}} being invoked.
>  
> Although this isn't technically a comprehensive fix, a quick option would be to invoke {{ConfigDef.parse(...)}} using the relevant client {{ConfigDef}} before passing overrides to the policy. Technically, this would still lead to problems if the policy decided to return just the name of a class for a config that of type class instead, so we may want to investigate other options as well.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)