-
Notifications
You must be signed in to change notification settings - Fork 14.1k
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
KAFKA-18211: Override class loaders for class graph scanning in connect. #18403
base: trunk
Are you sure you want to change the base?
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Are you able to write a regression test for this? Our existing test suite missed this on the library change.
Yes, made some updates and added a test for this scenario. On a side not, may I get auto approval to run the test suite on my PRs, will help with validating the Multiversion PRs. |
Sorry about that, clicking the approval button approves a single run and the label approves multiple runs. TIL |
@MethodSource("parameters") | ||
public void testClasspathPluginIsAlsoLoadedInIsolation(PluginScanner scanner) { | ||
// json converter is part of the classpath by default | ||
String jsonConverterLocation = JsonConverter.class.getProtectionDomain().getCodeSource().getLocation().getPath(); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This feels very brittle to me.
Rather than using a real class, can this use a TestPlugin with a similar name to a classpath plugin?
Or the last time we needed to set up a "classpath" plugin, it was by injecting a new loader in the hierarchy in PluginsTest#assertClassLoaderReadsVersionFromResource
.
// In addition, we need to explicitly specify the full classloader order, as classgraph only scans the classes available | ||
// in the classloaders and not the entire parent chain. Due to this reason if a plugin is extending a class present | ||
// in classpath/application it will not be able to find the parent class unless we explicitly specify the classloader order. | ||
List<ClassLoader> classLoaderOrder = new ArrayList<>(); | ||
ClassLoader cl = source.loader(); | ||
while (cl != null) { | ||
classLoaderOrder.add(cl); | ||
cl = cl.getParent(); | ||
} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is this true? What is the ignoreParentClassLoaders
method doing then?
Addresses the issue highlighted in https://issues.apache.org/jira/browse/KAFKA-18211
Committer Checklist (excluded from commit message)