Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

refactor: remove usage of the org.apache.kafka.connect.runtime library #9561

Merged
merged 14 commits into from
Sep 27, 2022

Conversation

jzaralim
Copy link
Contributor

Description

org.apache.kafka.connect.runtime is an internal library so we should avoid using it. There was a previous attempt to do this in #8990, but it was closed because we were lacking integration tests. They got added in #9500 , so we're revisiting this.

Testing done

Integration tests still pass

Reviewer checklist

  • Ensure docs are updated if necessary. (eg. if a user visible feature is being added or changed).
  • Ensure relevant issues are linked (description should include text like "Fixes #")

@jzaralim jzaralim requested a review from a team as a code owner September 14, 2022 21:46
Copy link
Contributor

@vcrfxia vcrfxia left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks @jzaralim ! LGTM with a few things inline.

Also, can you run a quick manual check that LIST CONNECTOR PLUGINS; works as expected with these changes, in the case where at least one plugin is returned? Our integration test coverage for connector functionality only has a test case where no connector plugins are expected to be returned since it was tricky to add a connector plugin for the test.

private final ConnectorType type;

@JsonCreator
public ConnectorInfo(
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why did tasks get removed from this? This class appears to be user-facing, since it's returned from the response of CREATE CONNECTOR. It'd be good to go through the other user-facing classes to double-check that those aren't dropping fields as well, since we don't know how users might be using these additional fields today.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Added all the removed fields back.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Some of them aren't user-facing, right? It looks like ConfigInfos might only be used internally, in which case it's fine to leave out the extra fields from that. It's just the user-facing ones like ConnectorInfo that it'd be good to keep extra fields for, for purposes of backwards compatibility.

@@ -701,11 +702,11 @@ public void shouldPrintConnectorPluginsList() {
+ " \"warnings\" : [ ]," + NEWLINE
+ " \"connectorsPlugins\" : [ {" + NEWLINE
+ " \"className\" : \"clazz1\"," + NEWLINE
+ " \"type\" : \"source\"," + NEWLINE
+ " \"type\" : \"SOURCE\"," + NEWLINE
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

How come this is uppercased now? It looks like the new PluginType class that got copied over also has toLowerCase() in its toString() method.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

PluginType was missing the JsonValue annotation so it wasn't even calling toString 🤦 fixed

import java.util.Objects;
import org.apache.kafka.connect.runtime.rest.entities.ConnectorType;
import org.apache.kafka.common.config.provider.ConfigProvider;
import org.apache.kafka.connect.connector.policy.ConnectorClientConfigOverridePolicy;
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Are there follow-up plans to remove these non-runtime usages of connect libraries as well, or was it just the runtime ones which were causing trouble?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

No, just these ones. Most of the other connect libraries would either be too complicated to remove (the connect executable) or are risky wrt backwards compatibility (related to serialization).

Copy link
Contributor

@vcrfxia vcrfxia left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks @jzaralim ! LGTM pending the manual test request from my previous review.

@jzaralim jzaralim merged commit 1726ed1 into master Sep 27, 2022
@jzaralim jzaralim deleted the connect-libs branch September 27, 2022 06:33
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants