[
https://issues.apache.org/jira/browse/KAFKA-6417?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16416201#comment-16416201
]
Chris Egerton commented on KAFKA-6417:
--------------------------------------
Curious--why do you think false positives would be a big issue? Do most users
(that you know of and/or that have encountered this issue) have nested
directories included in their {{plugin.path}} (e.g.,
{{plugin.path=foo/bar,foo/bar/baz}}) and/or a bunch of unnecessary JARs lying
around?
If we make it clear that we're only warning that the JAR we've encountered
won't be used as a dependency for plugin JARs in the same directory, the
warning can be safely ignored by anyone reading it who isn't encountering an
issue instantiating a given plugin but will be useful for anyone who is, as
long as they don't have nested directories in their {{plugin.path}}.
To be clear, your suggestion for altering the plugin scanning behavior is
essentially that we no longer differentiate uber JARs from other JARs and place
all JAR files for a plugin in a directory underneath a directory supplied as a
plugin path, correct? Can ask around to see what people think about that before
writing up a KIP but it seems like a bit of a nuclear option given the
compatibility issues you mentioned.
RE: failing individual plugins: Have to dig into the code base more to verify
this, but that could be as simple as adding another {{catch}} block for the
{{ClassNotFoundException}} that gets thrown under these circumstances and
outputting an appropriate error message about not being able to use the
connector, similar to [what is already
done|https://github.com/apache/kafka/blob/395c7e0f0985b424ea2bc2bd40c0237eada24dcf/connect/runtime/src/main/java/org/apache/kafka/connect/runtime/isolation/DelegatingClassLoader.java#L183-L189]
in the plugin scanning phase for Connect. Thoughts?
> plugin.path pointing at a plugin directory causes ClassNotFoundException
> ------------------------------------------------------------------------
>
> Key: KAFKA-6417
> URL: https://issues.apache.org/jira/browse/KAFKA-6417
> Project: Kafka
> Issue Type: Bug
> Components: KafkaConnect
> Affects Versions: 1.0.0
> Reporter: Dustin Cote
> Priority: Major
>
> When using the {{plugin.path}} configuration for the Connect workers, the
> user is expected to specify a list containing the following per the docs:
> {quote}
> The list should consist of top level directories that include any combination
> of: a) directories immediately containing jars with plugins and their
> dependencies b) uber-jars with plugins and their dependencies c) directories
> immediately containing the package directory structure of classes of plugins
> and their dependencies
> {quote}
> This means we would expect {{plugin.path=/usr/share/plugins}} for a structure
> like {{/usr/share/plugins/myplugin1}},{{/usr/share/plugins/myplugin2}}, etc.
> However if you specify {{plugin.path=/usr/share/plugins/myplugin1}} the
> resulting behavior is that dependencies for {{myplugin1}} are not properly
> loaded. This causes a {{ClassNotFoundException}} that is not intuitive to
> debug.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
