[
https://issues.apache.org/jira/browse/KAFKA-6417?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16416232#comment-16416232
]
Dustin Cote commented on KAFKA-6417:
------------------------------------
[~ChrisEgerton] yeah it's a bit extreme probably to kill the whole worker, so
just failing the non-conforming connector is better IMO. However, the
convention today is pretty convoluted and I think the pain of breaking
compatibility (for some major release) isn't so bad.
We do have lots of users with polluted classpaths, especially coming from a
hadoop world where they just have hundreds of jars on their system that they
don't really manage themselves. The original report of this actually came from
that type of situation and once you're there it's hard to figure out what's
going on. Adding more stuff in the log might help if you know what you are
looking for a priori but coming at it from just a ClassNotFoundException, you
have hundreds of jars to sift through the point gets lost a bit. A user may be
thinking "if I'm missing a class why do I have this repeated message that these
JARs won't be used as a dependency?" This is a more complex problem for a user
to solve than, "my worker said it went down because I have JARs where they
shouldn't be". The corrective action for the former is pretty unclear, but the
latter I think the action is clear and if a class isn't found in that case you
know what directory to look in.
> 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)
