[
https://issues.apache.org/jira/browse/KAFKA-6417?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16419740#comment-16419740
]
Chris Egerton commented on KAFKA-6417:
--------------------------------------
[~cotedm] I _think_ that the behavior for several uber-JAR'd plugins in a
shared directory would be that each plugin would be picked up by the Connect
framework, but all class loading for those plugins would occur with a single
classpath containing all of those JARs, leading to dependency overlaps that the
{{plugin.path}} configuration was implemented to prevent in the first place.
And I really like the point that "each plugin needs {{directory/jars}} as the
structure", or even just "each plugin needs its own directory"; seems much
easier to explain and we can establish the correlation between a plugin having
its own directory and a plugin having its own classpath isolation.
[~rhauch] Thanks for pointing us towards that--I think that's a good approach,
although for this particular case we might also want to include information on
which plugins are understood as coming from uber JARs and which aren't.
Otherwise, we may further confuse users who see that their plugin _was_ found
by the framework, but somehow still triggered a {{ClassNotFoundException}}
later on down the road. If we end up adjusting the behavior of {{plugin.path}}
to force all plugins to have their own directories, essentially treating uber
JARs just like any other JAR, then such a distinction would no longer be
necessary. What are your thoughts on altering the plugin structure to force
each plugin, even ones contained in uber JARs, to have its own subdirectory
underneath a directory listed for {{plugin.path}}?
> 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)
