1. 15 4月, 2014 2 次提交
  2. 25 3月, 2014 1 次提交
  3. 24 3月, 2014 1 次提交
  4. 22 2月, 2014 1 次提交
    • J
      [FIXED JENKINS-12124] Occasionally errors loading plugin classes since it is... · 898f1f76
      Jesse Glick 提交于
      [FIXED JENKINS-12124] Occasionally errors loading plugin classes since it is expected that findClass (and findLoadedClass) are called under synchronization.
      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.
      898f1f76
  5. 18 2月, 2014 1 次提交
  6. 04 1月, 2014 1 次提交
  7. 10 12月, 2013 1 次提交
  8. 15 11月, 2013 2 次提交
  9. 26 10月, 2013 1 次提交
    • K
      [JENKINS-19383] · f98c4627
      Kohsuke Kawaguchi 提交于
      Escape hatch to disable bytecode transformation in case this causes other unforeseen problems.
      f98c4627
  10. 05 10月, 2013 2 次提交
  11. 27 8月, 2013 1 次提交
  12. 03 8月, 2013 1 次提交
    • K
      [FIXED JENKINS-18677] · 47de54d0
      Kohsuke Kawaguchi 提交于
      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.
      47de54d0
  13. 08 7月, 2013 1 次提交
  14. 08 6月, 2013 1 次提交
    • K
      [FIXED JENKINS-15120] · f7330d7a
      Kohsuke Kawaguchi 提交于
      - 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.
      f7330d7a
  15. 20 12月, 2012 1 次提交
  16. 09 12月, 2012 1 次提交
  17. 17 11月, 2012 1 次提交
  18. 16 6月, 2012 1 次提交
  19. 31 5月, 2012 1 次提交
  20. 30 5月, 2012 1 次提交
    • K
      External monitor job type is moved to a plugin. · 903bf089
      Kohsuke Kawaguchi 提交于
      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.
      903bf089
  21. 10 2月, 2012 1 次提交
  22. 04 1月, 2012 1 次提交
  23. 10 10月, 2011 4 次提交
  24. 09 9月, 2011 4 次提交
  25. 30 8月, 2011 1 次提交
    • K
      Reverting 4de81f1e. · f322503d
      Kohsuke Kawaguchi 提交于
      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 4de81f1e, 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
      f322503d
  26. 24 7月, 2011 1 次提交
  27. 23 7月, 2011 1 次提交
  28. 18 7月, 2011 1 次提交
  29. 18 6月, 2011 1 次提交
  30. 29 5月, 2011 2 次提交