[
https://issues.apache.org/jira/browse/KAFKA-14649?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Greg Harris updated KAFKA-14649:
--------------------------------
Description:
Connect plugin path scanning evaluates the version() method of plugins to
determine which version of a plugin to load, and what version to advertise as
part of the REST API. This process involves reflectively constructing an
instance of the class and calling the version method, which can fail in the
following scenarios:
1. If a plugin throws an exception from a static initialization block
2. If a plugin does not have a default constructor (such as a non-static inner
class)
3. If a plugin has a default constructor is not public
4. If a plugin throws an exception from the default constructor
5. If a plugin's version method throws an exception
If any of the above is true for any single connector or rest extension on the
classpath or plugin.path, the plugin path scanning will exit early, and
potentially hide other unrelated plugins. This is primarily an issue in
development and test environments, because they are easy-to-make code mistakes
that would generally not make it to a release. Exceptions from the version
method, however, can cause the worker to throw
It is desirable for the worker to instead log these exceptions and continue.
This will prevent one mis-implemented plugin from affecting other plugins,
while still causing integration tests to fail against the plugin itself. We can
augment logging to make it clear how to correct these failures, where before it
was rather opaque and difficult to debug.
was:
Connect plugin path scanning evaluates the version() method of plugins to
determine which version of a plugin to load, and what version to advertise as
part of the REST API. This process involves reflectively constructing an
instance of the class and calling the version method, which can fail in the
following scenarios:
1. If a plugin throws an exception from a static initialization block
2. If a plugin does not have a default constructor (such as a non-static inner
class)
3. If a plugin has a default constructor is not public
4. If a plugin throws an exception from the default constructor
5. If a plugin's version method throws an exception
If any of the above is true for any single connector or rest extension on the
classpath or plugin.path, the worker will fail to start up entirely. This is
primarily an issue in development and test environments, because they are
easy-to-make code mistakes that would generally not make it to a release.
It is desirable for the worker to instead log these exceptions and continue.
This will prevent one mis-implemented plugin from affecting other plugins,
while still causing integration tests to fail against the plugin itself. We can
augment logging to make it clear how to correct these failures, where before it
was rather opaque and difficult to debug.
> Failures instantiating Connect plugins hides other plugins from REST API
> ------------------------------------------------------------------------
>
> Key: KAFKA-14649
> URL: https://issues.apache.org/jira/browse/KAFKA-14649
> Project: Kafka
> Issue Type: Bug
> Components: KafkaConnect
> Affects Versions: 3.1.0, 3.0.0, 3.2.0, 3.3.0, 3.4.0
> Reporter: Greg Harris
> Assignee: Greg Harris
> Priority: Minor
>
> Connect plugin path scanning evaluates the version() method of plugins to
> determine which version of a plugin to load, and what version to advertise as
> part of the REST API. This process involves reflectively constructing an
> instance of the class and calling the version method, which can fail in the
> following scenarios:
> 1. If a plugin throws an exception from a static initialization block
> 2. If a plugin does not have a default constructor (such as a non-static
> inner class)
> 3. If a plugin has a default constructor is not public
> 4. If a plugin throws an exception from the default constructor
> 5. If a plugin's version method throws an exception
> If any of the above is true for any single connector or rest extension on the
> classpath or plugin.path, the plugin path scanning will exit early, and
> potentially hide other unrelated plugins. This is primarily an issue in
> development and test environments, because they are easy-to-make code
> mistakes that would generally not make it to a release. Exceptions from the
> version method, however, can cause the worker to throw
> It is desirable for the worker to instead log these exceptions and continue.
> This will prevent one mis-implemented plugin from affecting other plugins,
> while still causing integration tests to fail against the plugin itself. We
> can augment logging to make it clear how to correct these failures, where
> before it was rather opaque and difficult to debug.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
