The problem was masked by a blind assumption that an InvocationTargetException was in fact wrapping a ClassNotFoundException.
Many thanks to @gotwarlost for demonstrating how to reproduce the problem and diagnosing the cause.
Integrated bytecode-compatibility-transformer that allows core to
do signature changes on properties that plugins might depend on.
The library performs necessary bytecode transformation to achieve this.
The first use of this is to fix plugins that looks for List
AbstractProject.triggers, thereby resolving JENKINS-18677.
For the time being, I'm not loading such compatibility annotations from
plugins, but I did code that in PluginManager. Let's see how this
feature work out for a while in the core, and if it looks stable and
solid, we'll open it up to plugins at that point.
- integrated the newer release of remoting
- jar caching won't work with class file directory, so plugin
WEB-INF/classes are now exploded as WEB-INF/lib/classes.jar
(This should also solve the problem of slow plugin extraction in the
presene of Anti-virus software on Windows.)
- because the structure of the exploded jar file has changed, I changed
the up-to-date check timestamp file name to force re-extraction in
existing installations.
The actual release needs to happen in a lock step, as the new plugin
needs to require yet-to-be-released version of the core. So for the time
being it's a snapshot dependency, deployed in the snapshot repository.
Max Spring discovered a stack overflow in http://jenkins.361315.n4.nabble.com/channel-example-and-plugin-classes-gives-ClassNotFoundException-td3756092.html that pointed this call into thread context classloader (TCL) as the culprit. Independently, Paul Sandoz discovered the same issue in our products. If TCL is another classloader that delegates to UberClassLoader (UCL), this code causes infinite recursion.
And moreover, given the goal of UCL, it seems wrong that this class is changing behaviour based on contextual information like TCL.
In looking at 4de81f1eb3, the change was introduced to make sure XStream unmarshalling invoked from Plugin.start() would see the classes in that plugin. This was an issue back then when plugins are prepared and loaded one by one, as UCL didn't have visibility into plugins being prepared. But in the current Jenkins, classloaders for all the plugins are prepared, before any plugin gets started, so by the time Plugin.start() runs, UCL is fully functioning.
Therefore, there's no need to consult TCL for the purpose of resolving its own classes. I could have also removed the code that sets TCL, but because some libraries often depend on TCL and doesn't properly look at caller class, I'm leaving it in, even though it's generally a bad practice to rely on TCL in multi-classloader apps like Jenkins
installed plugins page. DependencyClassLoader checks dependencies before
this plugin, so wrong index.jelly is found for plugins with dependencies.
Added implementation of findResources in DependencyClassLoader, and use
getResources to find the right index.jelly in PluginWrapper.getIndexPage().
git-svn-id: https://hudson.dev.java.net/svn/hudson/trunk/hudson/main@32876 71c3de6d-444a-0410-be80-ed276b4c234a
Jesse Glick