Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.Sign up
[core] LanguageRegistry uses default class loader when invoking ServiceLocator #1377
Affects PMD Version:
In Jenkins warnings plugin I am using PMD core to read and print the descriptions of the warnings rules. I use the class
@uhafner I'm having a little trouble understanding your scenario.
You seem to be building a Jenkins plugin, which uses PMD. PMD is hence a direct dependency of your plugin and bundled with it (ie: present in the same classloader that loads and runs the plugin).
Jenkins is probably creating a separate classloader to run the plugin (as it's standard practice, to avoid conflicts on different versions of the same dependency), but that classloader probably references the Jenkins classloader as parent classloader to share the Jenkins API classes. Is this assumption correct?
In that scenario, anything in the Jenkins classloader is available to your plugin in the default classloader. And even without the parent classloader, if a classloader loaded your plugin's classes, it MUST have access to the PMD classes (as it's bundled together, and the fact you are not getting a
@uhafner thanks for the info! if I understand correctly, changing:
ServiceLoader<Language> languageLoader = ServiceLoader.load(Language.class, getClass().getClassLoader());
would be enough, as Jenkins loads the classes from the proper classloader, it's simply not the default context one for the current thread, right?
added a commit
Oct 15, 2018
referenced this issue
Oct 15, 2018
@uhafner The fix has been integrated now. Could you test, whether the problem is gone now?
Simply use PMD version 6.9.0-SNAPSHOT from