[
https://issues.apache.org/jira/browse/KAFKA-6417?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16416174#comment-16416174
]
Chris Egerton edited comment on KAFKA-6417 at 3/27/18 8:18 PM:
---------------------------------------------------------------
Sorry, started working on this comment before I saw yours, [~cotedm]; I'll
address your points now in a separate one.
There's also the case where a plugin performs some operations either statically
or, in the case of a connector, in its no-args constructor, in which case the
resulting {{ClassNotFoundException}} is thrown while starting up connect (in
either distributed or standalone mode), and causes the framework to crash.
If this happens, there's no guarantee that any of the non-plugin-containing
JARs would be scanned before the plugin JAR itself is scanned and the
framework-halting exception is thrown, so we can't rely on the user having seen
any warnings beforehand about non-plugin-containing JARs not being used as
dependencies for other plugins.
Handling this separate case could involve intercepting the
{{ClassNotFoundException}} and outputting a similar warning message about
improper plugin path structure, before throwing the same exception and causing
the framework to halt like before.
was (Author: chrisegerton):
There's also the case where a plugin performs some operations either statically
or, in the case of a connector, in its no-args constructor, in which case the
resulting {{ClassNotFoundException}} is thrown while starting up connect (in
either distributed or standalone mode), and causes the framework to crash.
If this happens, there's no guarantee that any of the non-plugin-containing
JARs would be scanned before the plugin JAR itself is scanned and the
framework-halting exception is thrown, so we can't rely on the user having seen
any warnings beforehand about non-plugin-containing JARs not being used as
dependencies for other plugins.
Handling this separate case could involve intercepting the
{{ClassNotFoundException}} and outputting a similar warning message about
improper plugin path structure, before throwing the same exception and causing
the framework to halt like before.
> 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)
