[jira] [Updated] (KAFKA-14649) Failures instantiating Connect plugins hides other plugins from REST API, or crash worker
[ https://issues.apache.org/jira/browse/KAFKA-14649?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Chris Egerton updated KAFKA-14649: -- Fix Version/s: 3.4.1 > Failures instantiating Connect plugins hides other plugins from REST API, or > crash worker > - > > 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 > Fix For: 3.5.0, 3.4.1 > > > 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 fail to start up as they are > uncaught. > 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)
[jira] [Updated] (KAFKA-14649) Failures instantiating Connect plugins hides other plugins from REST API, or crash worker
[ 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 fail to start up as they are uncaught. 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 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. > Failures instantiating Connect plugins hides other plugins from REST API, or > crash worker > - > > 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 fail to start up as they are > uncaught. > It is desirable for the worker to instead log these exceptions and continue. > This will prevent one mis-implemented plugin from affecting other plugins,
[jira] [Updated] (KAFKA-14649) Failures instantiating Connect plugins hides other plugins from REST API, or crash worker
[ https://issues.apache.org/jira/browse/KAFKA-14649?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Greg Harris updated KAFKA-14649: Summary: Failures instantiating Connect plugins hides other plugins from REST API, or crash worker (was: Failures instantiating Connect plugins hides other plugins from REST API) > Failures instantiating Connect plugins hides other plugins from REST API, or > crash worker > - > > 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)
