gharris1727 opened a new pull request, #13977: URL: https://github.com/apache/kafka/pull/13977
The ClasspathHelper.forJavaClassPath disregards all intermediate classloaders between the AppClassLoader and the DelegatingClassLoader, when those classloaders may contain plugins. Instead, plugins in those intermediate classloaders should be discoverable, for parity with the ServiceLoaderScanner. This behavior is added as two assertions to the existing `PluginsTest.assertClassLoaderReadsVersionFromResource` which already sets up a classloader hierarchy that replicates this situation. Once this bug is fixed however, the `PluginsTest.pluginClassLoaderReadVersionFromResourceExistingInParentAndChild` fails for a different reason: the Plugins class begins to load the wrong copy of the ReadVersionFromResource plugin. The presence of the plugin in both the parent loader and the plugin path forces the Plugins infrastructure to make a decision about which to load, when previously it always loaded the only copy visible, the one in the plugin.path. By default, it will prefer classpath plugins when the versions of plugins are equal, causing it to pick the parent copy of the plugin, which fails the test. To tweak the load order, make the ReadVersionFromResource plugin versioned, such that the "2.0.0" version is preferred, and is loaded during the test. ### Committer Checklist (excluded from commit message) - [ ] Verify design and implementation - [ ] Verify test coverage and CI build status - [ ] Verify documentation (including upgrade notes) -- 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
