[ 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)