C0urante commented on code in PR #13771:
URL: https://github.com/apache/kafka/pull/13771#discussion_r1212239852
##########
connect/runtime/src/main/java/org/apache/kafka/connect/runtime/isolation/PluginUtils.java:
##########
@@ -356,25 +357,16 @@ public static String prunedName(PluginDesc<?> plugin) {
* Verify whether a given plugin's alias matches another alias in a
collection of plugins.
*
* @param alias the plugin descriptor to test for alias matching.
- * @param plugins the collection of plugins to test against.
+ * @param aliases the collection of plugins to test against.
* @param <U> the plugin type.
* @return false if a match was found in the collection, otherwise true.
*/
public static <U> boolean isAliasUnique(
PluginDesc<U> alias,
- Collection<PluginDesc<U>> plugins
+ Map<String, String> aliases
) {
- boolean matched = false;
- for (PluginDesc<U> plugin : plugins) {
- if (simpleName(alias).equals(simpleName(plugin))
- || prunedName(alias).equals(prunedName(plugin))) {
- if (matched) {
- return false;
- }
- matched = true;
- }
- }
- return true;
+ // TODO: Mark alias collision and disable ambiguous aliases completely.
Review Comment:
Ah, gotcha--thanks for the clarification 👍
I find the ambiguity that we permit on trunk pretty distasteful, but it's
also possible that there are connectors/Kafka Connect clusters out there that
are working because of it.
I have no problem with eliminating that ambiguity when using service
loader-based plugin discovery.
I have some qualms about eliminating it when using the existing plugin
scanning-based discovery. Would it add too much implementation complexity to
either preserve the existing behavior (ugly though it is), or at least emit
clear error messages in exceptions that get thrown during connector startup
and/or config validation?
I think I could live with it if we eliminated ambiguity altogether since the
existing behavior feels like the result of an oversight and may be difficult to
preserve, but since you're in the neighborhood, it'd be nice to have your
thoughts on what (if anything) we can do to reasonably accommodate our users if
they're currently relying on it.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: jira-unsubscr...@kafka.apache.org
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
