[
https://issues.apache.org/jira/browse/KAFKA-8550?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16866106#comment-16866106
]
ASF GitHub Bot commented on KAFKA-8550:
---------------------------------------
C0urante commented on pull request #6959: KAFKA-8550: Fix plugin loading of
aliased converters in Connect
URL: https://github.com/apache/kafka/pull/6959
[Jira](https://issues.apache.org/jira/browse/KAFKA-8550)
Summary of issue: connector validation fails if an alias is used for the
converter since the validation for that is done via
`ConfigDef.validateAll(...)`, which in turn invokes `Class.forName(...)` on the
alias. Even though the class is successfully loaded by the
`DelegatingClassLoader`, some Java implementations will refuse to return a
class from `Class.forName(...)` whose name differs than the argument provided.
Summary of fix: alter `ConfigDef.parseType(...)` to _first_ invoke
`ClassLoader.loadClass(...)` on the class in order to get a handle on the
actual class object to be loaded, _then_ invoke `Class.forName(...)` with the
fully-qualified class name of the to-be-loaded class and return the result. The
invocation of `Class.forName(...)` is necessary in order to allow static
initialization to take place; simply calling `ClassLoader.loadClass(...)` is
insufficient.
Summary of testing: tested manually on trunk. Added unit test to
`ConfigDefTest` that simulates the plugin-aliasing behavior of the
`DelegatingClassLoader` and then invokes `ConfigDef.parseType` on an aliased
class; this test fails on the current trunk but succeeds with the changes
proposed here.
This should be backported at _least_ to 2.0; it's likely the issue goes back
further than that but since it's been around for so long and has yet to be
noted by anyone else it doesn't seem worth the effort to backport that much
further if there are any significant merge conflicts.
### 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:
us...@infra.apache.org
> Connector validation fails with aliased converters
> --------------------------------------------------
>
> Key: KAFKA-8550
> URL: https://issues.apache.org/jira/browse/KAFKA-8550
> Project: Kafka
> Issue Type: Bug
> Components: KafkaConnect
> Affects Versions: 2.0.2, 2.3.0, 2.1.2, 2.2.2
> Reporter: Chris Egerton
> Assignee: Chris Egerton
> Priority: Major
>
> During connector config validation,
> [ConfigDef.validateAll(...)|https://github.com/apache/kafka/blob/1ae92914e28919a97520e91bfd0e588d55eb1774/clients/src/main/java/org/apache/kafka/common/config/ConfigDef.java#L497-L513]
> is invoked using a [Connector
> ConfigDef|https://github.com/apache/kafka/blob/trunk/connect/runtime/src/main/java/org/apache/kafka/connect/runtime/ConnectorConfig.java].
> This ConfigDef contains definitions for the [key and value
> converters|https://github.com/apache/kafka/blob/1ae92914e28919a97520e91bfd0e588d55eb1774/connect/runtime/src/main/java/org/apache/kafka/connect/runtime/ConnectorConfig.java#L72-L78],
> which have the type
> [ConfigDef.Type.CLASS|https://github.com/apache/kafka/blob/1ae92914e28919a97520e91bfd0e588d55eb1774/connect/runtime/src/main/java/org/apache/kafka/connect/runtime/ConnectorConfig.java#L167-L168].
> When plugin aliases are used for these configs, an error is encountered and
> the connector configuration is rejected.
> This error occurs because
> [Class.forName(...)|https://docs.oracle.com/javase/8/docs/api/java/lang/Class.html#forName-java.lang.String-boolean-java.lang.ClassLoader-]
> is used to load the classes for these configs during validation. Even though
> the DelegatingClassLoader used by Connect successfully loads the requested
> class in its
> [loadClass(...)|https://github.com/apache/kafka/blob/1ae92914e28919a97520e91bfd0e588d55eb1774/connect/runtime/src/main/java/org/apache/kafka/connect/runtime/isolation/DelegatingClassLoader.java#L358-L376]
> method, some (if not all) implementations of the Java runtime will then
> perform a check in their native Class.forName method to verify that the name
> of the loaded class matches the requested class name. For example, see [this
> section of
> OpenJDK|https://github.com/openjdk/jdk/blob/515e7600df738ebf8c42d38e322def012385e1b9/src/hotspot/share/classfile/systemDictionary.cpp#L1508-L1528]
> that performs the aforementioned check.
> A few possible fixes that come to mind include altering the connector
> validation in the AbstractHerder class to not use the
> ConfigDef.validateAll(...) method, or altering the logic used by the
> ConfigDef in its validateAll method for configs of type ConfigDef.Type.CLASS
> to use
> [ClassLoader.loadClass(...)|https://docs.oracle.com/javase/8/docs/api/java/lang/ClassLoader.html#loadClass-java.lang.String-]
> either instead of or in addition to Class.forName(...).
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
