Skip to content

Conversation

@majialoong
Copy link
Contributor

@majialoong majialoong commented Sep 29, 2025

In this PR, we added some
validation checks for the connect config, such as ensuring that
plugin.path cannot be empty.

However, currently, Connect first loads the plugin and then creates the
configuration. Even if plugin.path is empty, it still attempts to load
the plugin first, and then throws an exception when creating the
configuration.

The approach should be to first create a configuration to validate that
the config meet the requirements, and then load the plugin only if the
validation passes. This allows for early detection of problems and
avoids unnecessary plugin loading processes.

Reviewers: Ken Huang s7133700@gmail.com, Chia-Ping Tsai
chia7712@gmail.com

@github-actions github-actions bot added triage PRs from the community connect small Small PRs labels Sep 29, 2025
@Yunyung
Copy link
Collaborator

Yunyung commented Sep 29, 2025

Thanks for the PR. It looks like this also happened for MirrorMaker.

@majialoong
Copy link
Contributor Author

@Yunyung Thank you for pointing this out, MirrorMaker has also been adjusted.

@github-actions github-actions bot added the tools label Sep 30, 2025
@majialoong
Copy link
Contributor Author

Hello, @Yunyung @chia7712 @m1a2st , when have time, please review this PR , thanks !

try {
Path pluginPathElement = Paths.get(path).toAbsolutePath();
if (pluginPath.isEmpty()) {
if (path.isEmpty()) {
Copy link
Member

Choose a reason for hiding this comment

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

Is this a bug fix?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

First, in this PR, plugin.path is defined as a non-empty parameter, so this conditional statement should never be executed.

Second, I think this conditional statement was ambiguous. The warning log indicates that the plugin path element is empty, but the actual check is for the entire plugin path, not just the element.

Therefore, we can either remove this conditional statement(since plugin.path cannot be empty), or modify it to better match the warning log message about an empty plugin path element. I prefer the latter approach.

Copy link
Collaborator

Choose a reason for hiding this comment

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

I think we can remove this check, the path.isEmpty() statement will also never be executed. The List.validator already validates empty values in the list.

throw new ConfigException("Configuration '" + name + "' values must not be empty.");

Copy link
Collaborator

Choose a reason for hiding this comment

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

I think we should also update the ConnectPluginPath class to validate that plugin.path is not empty. However, this change might require a separate KIP or an update to KIP-1161 to address it.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

I think we should also update the ConnectPluginPath class to validate that plugin.path is not empty. However, this change might require a separate KIP or an update to KIP-1161 to address it.

Thanks for your suggestions. I will submit a separate patch to fix the ConnectPluginPath issue; this patch removes the corresponding changes.

}
String pluginPath = properties.getProperty(WorkerConfig.PLUGIN_PATH_CONFIG);
if (pluginPath != null) {
if (pluginPath != null && !pluginPath.isEmpty()) {
Copy link
Member

Choose a reason for hiding this comment

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

ditto

Copy link
Contributor Author

Choose a reason for hiding this comment

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

In this PR, plugin.path is defined to not be empty. Therefore, I think some adjustments are needed here to align with the definition of "non-empty."

Copy link
Contributor Author

Choose a reason for hiding this comment

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

@chia7712 If you think these two changes shouldn't be included in this PR I can make them separately in another PR.

Copy link
Member

Choose a reason for hiding this comment

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

yes, it would be nice to have a separate PR to revisit those checks

@github-actions github-actions bot removed the triage PRs from the community label Oct 2, 2025
@chia7712 chia7712 merged commit 24cad50 into apache:trunk Oct 6, 2025
23 of 25 checks passed
@majialoong majialoong deleted the adjust-connect-config-create-timing branch October 21, 2025 14:09
eduwercamacaro pushed a commit to littlehorse-enterprises/kafka that referenced this pull request Nov 12, 2025
[In this PR](apache#20334), we added some
validation checks for the connect config, such as ensuring that
`plugin.path` cannot be empty.

 However, currently, Connect first loads the plugin and then creates the
configuration. Even if `plugin.path` is empty, it still attempts to load
the plugin first, and then throws an exception when creating the
configuration.

The approach should be to first create a configuration to validate that
the config meet the requirements, and then load the plugin only if the
validation passes. This allows for early detection of problems and
avoids unnecessary plugin loading processes.

Reviewers: Ken Huang <s7133700@gmail.com>, Chia-Ping Tsai
 <chia7712@gmail.com>
@gharris1727
Copy link
Contributor

@chia7712 @majialoong I don't think this change is correct.

The instantiation of the config must happen after the call to plugins.compareAndSwapWithDelegatingLoader();, otherwise plugin classes which are referenced within the body of the worker config but only present within the plugin.path won't be loadable.

e.g. a custom override policy is installed on the plugin.path and not the classpath, and is no longer able to be found during worker startup, or is initialized with the wrong thread context class loader.

@chia7712
Copy link
Member

a custom override policy is installed on the plugin.path and not the classpath, and is no longer able to be found during worker startup, or is initialized with the wrong thread context class loader.

oh, you are right. @majialoong would you mind opening a PR to revert this change? Also, could you please add either a test or a comment to prevent this error from happening again?

@majialoong
Copy link
Contributor Author

@gharris1727 I apologize for causing this error. I only focused on validating the plugin.path parameter and ignored the impact of other parameters. Thank you for pointing this out; I now understand the importance of this order.

I have reverted these changes in another PR #20891 and implemented unit tests to prevent the issue from recurring.

Could you please review it when you have time. Thank you again for pointing out the problem, and I apologize for the changes.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Projects

None yet

Development

Successfully merging this pull request may close these issues.

5 participants