Uploaded image for project: 'Jenkins'
  1. Jenkins
  2. JENKINS-14495

Exception: java.lang.RuntimeException: Failed to instantiate class hudson.plugins.parameterizedtrigger.TriggerBuilder

    • Icon: Bug Bug
    • Resolution: Fixed
    • Icon: Major Major
    • None
    • CentOS 6 x86_64, jre-1.7.0_04-fcs.x86_64, Jenkins 1.474, Parameterized trigger plugin 2.15

      Whenever I add a build step "trigger/call builds on other projects" and click save, I get the following error:

      Status Code: 500

      Exception: java.lang.RuntimeException: Failed to instantiate class hudson.plugins.parameterizedtrigger.TriggerBuilder from {"configs":

      {"block":true,"buildStepFailureThreshold":"FAILURE","failureThreshold":"FAILURE","projects":"SlaveJob1","unstableThreshold":"UNSTABLE"}

      ,"kind":"hudson.plugins.parameterizedtrigger.TriggerBuilder","stapler-class":"hudson.plugins.parameterizedtrigger.TriggerBuilder"}
      Stacktrace:
      javax.servlet.ServletException: java.lang.RuntimeException: Failed to instantiate class hudson.plugins.parameterizedtrigger.TriggerBuilder from {"configs":

      {"block":true,"buildStepFailureThreshold":"FAILURE","failureThreshold":"FAILURE","projects":"SlaveJob1","unstableThreshold":"UNSTABLE"}

      ,"kind":"hudson.plugins.parameterizedtrigger.TriggerBuilder","stapler-class":"hudson.plugins.parameterizedtrigger.TriggerBuilder"}
      at org.kohsuke.stapler.Stapler.tryInvoke(Stapler.java:616)
      at org.kohsuke.stapler.Stapler.invoke(Stapler.java:659)
      at org.kohsuke.stapler.MetaClass$6.doDispatch(MetaClass.java:241)
      at org.kohsuke.stapler.NameBasedDispatcher.dispatch(NameBasedDispatcher.java:53)
      at org.kohsuke.stapler.Stapler.tryInvoke(Stapler.java:574)
      at org.kohsuke.stapler.Stapler.invoke(Stapler.java:659)
      at org.kohsuke.stapler.MetaClass$6.doDispatch(MetaClass.java:241)
      at org.kohsuke.stapler.NameBasedDispatcher.dispatch(NameBasedDispatcher.java:53)
      at org.kohsuke.stapler.Stapler.tryInvoke(Stapler.java:574)
      at org.kohsuke.stapler.Stapler.invoke(Stapler.java:659)
      at org.kohsuke.stapler.Stapler.invoke(Stapler.java:488)
      at org.kohsuke.stapler.Stapler.service(Stapler.java:162)
      at javax.servlet.http.HttpServlet.service(HttpServlet.java:45)
      at winstone.ServletConfiguration.execute(ServletConfiguration.java:248)
      at winstone.RequestDispatcher.forward(RequestDispatcher.java:333)
      at winstone.RequestDispatcher.doFilter(RequestDispatcher.java:376)
      at hudson.util.PluginServletFilter$1.doFilter(PluginServletFilter.java:95)
      at hudson.util.PluginServletFilter.doFilter(PluginServletFilter.java:87)
      at winstone.FilterConfiguration.execute(FilterConfiguration.java:194)
      at winstone.RequestDispatcher.doFilter(RequestDispatcher.java:366)
      at hudson.security.csrf.CrumbFilter.doFilter(CrumbFilter.java:47)
      at winstone.FilterConfiguration.execute(FilterConfiguration.java:194)
      at winstone.RequestDispatcher.doFilter(RequestDispatcher.java:366)
      at hudson.security.ChainedServletFilter$1.doFilter(ChainedServletFilter.java:84)
      at hudson.security.UnwrapSecurityExceptionFilter.doFilter(UnwrapSecurityExceptionFilter.java:51)
      at hudson.security.ChainedServletFilter$1.doFilter(ChainedServletFilter.java:87)
      at org.acegisecurity.ui.ExceptionTranslationFilter.doFilter(ExceptionTranslationFilter.java:166)
      at hudson.security.ChainedServletFilter$1.doFilter(ChainedServletFilter.java:87)
      at org.acegisecurity.providers.anonymous.AnonymousProcessingFilter.doFilter(AnonymousProcessingFilter.java:125)
      at hudson.security.ChainedServletFilter$1.doFilter(ChainedServletFilter.java:87)
      at org.acegisecurity.ui.rememberme.RememberMeProcessingFilter.doFilter(RememberMeProcessingFilter.java:142)
      at hudson.security.ChainedServletFilter$1.doFilter(ChainedServletFilter.java:87)
      at org.acegisecurity.ui.AbstractProcessingFilter.doFilter(AbstractProcessingFilter.java:271)
      at hudson.security.ChainedServletFilter$1.doFilter(ChainedServletFilter.java:87)
      at org.acegisecurity.ui.basicauth.BasicProcessingFilter.doFilter(BasicProcessingFilter.java:173)
      at hudson.security.ChainedServletFilter$1.doFilter(ChainedServletFilter.java:87)
      at jenkins.security.ApiTokenFilter.doFilter(ApiTokenFilter.java:63)
      at hudson.security.ChainedServletFilter$1.doFilter(ChainedServletFilter.java:87)
      at org.acegisecurity.context.HttpSessionContextIntegrationFilter.doFilter(HttpSessionContextIntegrationFilter.java:249)
      at hudson.security.HttpSessionContextIntegrationFilter2.doFilter(HttpSessionContextIntegrationFilter2.java:66)
      at hudson.security.ChainedServletFilter$1.doFilter(ChainedServletFilter.java:87)
      at hudson.security.ChainedServletFilter.doFilter(ChainedServletFilter.java:76)
      at hudson.security.HudsonFilter.doFilter(HudsonFilter.java:164)
      at winstone.FilterConfiguration.execute(FilterConfiguration.java:194)
      at winstone.RequestDispatcher.doFilter(RequestDispatcher.java:366)
      at org.kohsuke.stapler.compression.CompressionFilter.doFilter(CompressionFilter.java:50)
      at winstone.FilterConfiguration.execute(FilterConfiguration.java:194)
      at winstone.RequestDispatcher.doFilter(RequestDispatcher.java:366)
      at hudson.util.CharacterEncodingFilter.doFilter(CharacterEncodingFilter.java:81)
      at winstone.FilterConfiguration.execute(FilterConfiguration.java:194)
      at winstone.RequestDispatcher.doFilter(RequestDispatcher.java:366)
      at winstone.RequestDispatcher.forward(RequestDispatcher.java:331)
      at winstone.RequestHandlerThread.processRequest(RequestHandlerThread.java:215)
      at winstone.RequestHandlerThread.run(RequestHandlerThread.java:138)
      at java.util.concurrent.Executors$RunnableAdapter.call(Unknown Source)
      at java.util.concurrent.FutureTask$Sync.innerRun(Unknown Source)
      at java.util.concurrent.FutureTask.run(Unknown Source)
      at winstone.BoundedExecutorService$1.run(BoundedExecutorService.java:77)
      at java.util.concurrent.ThreadPoolExecutor.runWorker(Unknown Source)
      at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source)
      at java.lang.Thread.run(Unknown Source)
      Caused by: java.lang.RuntimeException: Failed to instantiate class hudson.plugins.parameterizedtrigger.TriggerBuilder from {"configs":

      {"block":true,"buildStepFailureThreshold":"FAILURE","failureThreshold":"FAILURE","projects":"SlaveJob1","unstableThreshold":"UNSTABLE"}

      ,"kind":"hudson.plugins.parameterizedtrigger.TriggerBuilder","stapler-class":"hudson.plugins.parameterizedtrigger.TriggerBuilder"}
      at hudson.model.Descriptor.newInstance(Descriptor.java:575)
      at hudson.model.Descriptor.newInstancesFromHeteroList(Descriptor.java:912)
      at hudson.model.Descriptor.newInstancesFromHeteroList(Descriptor.java:899)
      at hudson.util.DescribableList.rebuildHetero(DescribableList.java:203)
      at hudson.model.Project.submit(Project.java:202)
      at hudson.model.Job.doConfigSubmit(Job.java:990)
      at hudson.model.AbstractProject.doConfigSubmit(AbstractProject.java:688)
      at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
      at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source)
      at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
      at java.lang.reflect.Method.invoke(Unknown Source)
      at org.kohsuke.stapler.Function$InstanceFunction.invoke(Function.java:288)
      at org.kohsuke.stapler.Function.bindAndInvoke(Function.java:151)
      at org.kohsuke.stapler.Function.bindAndInvokeAndServeResponse(Function.java:90)
      at org.kohsuke.stapler.MetaClass$1.doDispatch(MetaClass.java:111)
      at org.kohsuke.stapler.NameBasedDispatcher.dispatch(NameBasedDispatcher.java:53)
      at org.kohsuke.stapler.Stapler.tryInvoke(Stapler.java:574)
      ... 60 more
      Caused by: java.lang.IllegalArgumentException: Failed to instantiate class hudson.plugins.parameterizedtrigger.TriggerBuilder from {"configs":

      {"block":true,"buildStepFailureThreshold":"FAILURE","failureThreshold":"FAILURE","projects":"SlaveJob1","unstableThreshold":"UNSTABLE"}

      ,"kind":"hudson.plugins.parameterizedtrigger.TriggerBuilder","stapler-class":"hudson.plugins.parameterizedtrigger.TriggerBuilder"}
      at org.kohsuke.stapler.RequestImpl$TypePair.convertJSON(RequestImpl.java:633)
      at org.kohsuke.stapler.RequestImpl.bindJSON(RequestImpl.java:377)
      at org.kohsuke.stapler.RequestImpl.bindJSON(RequestImpl.java:373)
      at hudson.model.Descriptor.newInstance(Descriptor.java:566)
      ... 76 more
      Caused by: java.lang.IllegalArgumentException: Failed to convert the configs parameter of the constructor public hudson.plugins.parameterizedtrigger.TriggerBuilder(java.util.List)
      at org.kohsuke.stapler.RequestImpl$TypePair.convertJSON(RequestImpl.java:627)
      ... 79 more
      Caused by: java.lang.IllegalArgumentException: Failed to instantiate class hudson.plugins.parameterizedtrigger.BlockableBuildTriggerConfig from

      {"block":true,"buildStepFailureThreshold":"FAILURE","failureThreshold":"FAILURE","projects":"SlaveJob1","unstableThreshold":"UNSTABLE"}

      at org.kohsuke.stapler.RequestImpl$TypePair.convertJSON(RequestImpl.java:633)
      at org.kohsuke.stapler.RequestImpl$TypePair.convertJSON(RequestImpl.java:669)
      at org.kohsuke.stapler.RequestImpl.bindJSON(RequestImpl.java:377)
      at org.kohsuke.stapler.RequestImpl$TypePair.convertJSON(RequestImpl.java:625)
      ... 79 more
      Caused by: java.lang.IllegalArgumentException: Failed to convert the block parameter of the constructor public hudson.plugins.parameterizedtrigger.BlockableBuildTriggerConfig(java.lang.String,hudson.plugins.parameterizedtrigger.BlockingBehaviour,java.util.List,java.util.List)
      at org.kohsuke.stapler.RequestImpl$TypePair.convertJSON(RequestImpl.java:627)
      ... 82 more
      Caused by: java.lang.IllegalArgumentException: Unable to convert to class hudson.plugins.parameterizedtrigger.BlockingBehaviour
      at org.kohsuke.stapler.RequestImpl$TypePair.convertJSON(RequestImpl.java:688)
      at org.kohsuke.stapler.RequestImpl.bindJSON(RequestImpl.java:377)
      at org.kohsuke.stapler.RequestImpl$TypePair.convertJSON(RequestImpl.java:625)
      ... 82 more

          [JENKINS-14495] Exception: java.lang.RuntimeException: Failed to instantiate class hudson.plugins.parameterizedtrigger.TriggerBuilder

          I have exactly the same problem with Jenkins 1.474 and plugin version 1.15. The front end effect is that on adding a pramerterized trigger as build step, only the Headline appears. Adding the trigger a second time shows the complete form. Setting the blocking-checkbox and pressing save or apply returns the exception above.

          Frederik Fromm added a comment - I have exactly the same problem with Jenkins 1.474 and plugin version 1.15. The front end effect is that on adding a pramerterized trigger as build step, only the Headline appears. Adding the trigger a second time shows the complete form. Setting the blocking-checkbox and pressing save or apply returns the exception above.

          Fabio Plachetta added a comment - - edited

          Same for me here, just as Frederik and Romu reported. First adds an empty heading, then the correct content. After saving it crashes with above exception. I have Jenkins v1.474

          Fabio Plachetta added a comment - - edited Same for me here, just as Frederik and Romu reported. First adds an empty heading, then the correct content. After saving it crashes with above exception. I have Jenkins v1.474

          Tibor Ficsor added a comment -

          Same here, please share workaround if available. (Jenkins 1.474, Parameterized trigger plugin 2.15)

          Tibor Ficsor added a comment - Same here, please share workaround if available. (Jenkins 1.474, Parameterized trigger plugin 2.15)

          Stephan Grimm added a comment -

          It works after downgrading to Jenkins 1.471 and Parameterized Trigger Plugin 2.14.

          Stephan Grimm added a comment - It works after downgrading to Jenkins 1.471 and Parameterized Trigger Plugin 2.14.

          I can report I am experiencing the problem as well with 1.475. Existing jobs created before the upgrade still work fine, but I cannot use the Parameterized Trigger plugin for new jobs.

          Shawn M. Jones added a comment - I can report I am experiencing the problem as well with 1.475. Existing jobs created before the upgrade still work fine, but I cannot use the Parameterized Trigger plugin for new jobs.

          cjo9900 added a comment -

          It looks like some of the changes in the core of 1.474 have changed how the json is created, as taking a similar case for 1.473 and 2.15 of the plugin gives the json for that case

          {
          	"configs": 
          	{
          		"projects": "1_test", 
          		"block": 
          		{
          			"buildStepFailureThreshold": "FAILURE", 
          			"failureThreshold": "FAILURE", 
          			"unstableThreshold": "UNSTABLE"
          		}, 
          	},
          	"stapler-class": "hudson.plugins.parameterizedtrigger.TriggerBuilder", 
          	"kind": "hudson.plugins.parameterizedtrigger.TriggerBuilder"
          },
          

          and for the 1.474 with 2.15

          {
          "configs":
          	{
          		"block":true,
          		"buildStepFailureThreshold":"FAILURE",
          		"failureThreshold":"FAILURE",
          		"projects":"SlaveJob1",
          		"unstableThreshold":"UNSTABLE"
          	},
          "kind":"hudson.plugins.parameterizedtrigger.TriggerBuilder",
          "stapler-class":"hudson.plugins.parameterizedtrigger.TriggerBuilder"
          }
          

          you can see that block encloses three elements in 1.473, but in 1.474 these are at the same level, so it looks as if the optional block behaviour has changed.

          Which is used in the BlockableBuildTriggerConfig jelly that is used for the configs.

            <f:optionalBlock field="block" title="${%Block until the triggered projects finish their builds}" checked="${instance.block!=null}">
              <j:set var="descriptor" value="${app.getDescriptorOrDie(descriptor.getPropertyType(field).clazz)}" />
              <j:set var="instance" value="${instance[field]}"/>
              <st:include from="${descriptor}" page="${descriptor.configPage}" />
            </f:optionalBlock>
          

          cjo9900 added a comment - It looks like some of the changes in the core of 1.474 have changed how the json is created, as taking a similar case for 1.473 and 2.15 of the plugin gives the json for that case { "configs" : { "projects" : "1_test" , "block" : { "buildStepFailureThreshold" : "FAILURE" , "failureThreshold" : "FAILURE" , "unstableThreshold" : "UNSTABLE" }, }, "stapler-class" : "hudson.plugins.parameterizedtrigger.TriggerBuilder" , "kind" : "hudson.plugins.parameterizedtrigger.TriggerBuilder" }, and for the 1.474 with 2.15 { "configs" : { "block" : true , "buildStepFailureThreshold" : "FAILURE" , "failureThreshold" : "FAILURE" , "projects" : "SlaveJob1" , "unstableThreshold" : "UNSTABLE" }, "kind" : "hudson.plugins.parameterizedtrigger.TriggerBuilder" , "stapler-class" : "hudson.plugins.parameterizedtrigger.TriggerBuilder" } you can see that block encloses three elements in 1.473, but in 1.474 these are at the same level, so it looks as if the optional block behaviour has changed. Which is used in the BlockableBuildTriggerConfig jelly that is used for the configs. <f:optionalBlock field= "block" title= "${%Block until the triggered projects finish their builds}" checked= "${instance.block!= null }" > <j:set var = "descriptor" value= "${app.getDescriptorOrDie(descriptor.getPropertyType(field).clazz)}" /> <j:set var = "instance" value= "${instance[field]}" /> <st:include from= "${descriptor}" page= "${descriptor.configPage}" /> </f:optionalBlock>

          Owen Mehegan added a comment -

          Argh, this is hitting me too, and I use Parameterized Trigger all over the place

          Owen Mehegan added a comment - Argh, this is hitting me too, and I use Parameterized Trigger all over the place

          cjo9900 added a comment -

          Looks to be the same issue as JENKINS-14514 as the build triggers are displayed using <f:repeatable>

          However the issue still occurs with that fix included.

          The new behaviour with 1.477-SNAPSHOT is that the configuration section is displayed, with the <f:optionalBlock field="block"> expanded even though the checkbox is unchecked which is incorrect.

          @Jesse can you look at this as it is related to the jelly and javascript changes that have been made in 1.474+.

          cjo9900 added a comment - Looks to be the same issue as JENKINS-14514 as the build triggers are displayed using <f:repeatable> However the issue still occurs with that fix included. The new behaviour with 1.477-SNAPSHOT is that the configuration section is displayed, with the <f:optionalBlock field="block"> expanded even though the checkbox is unchecked which is incorrect. @Jesse can you look at this as it is related to the jelly and javascript changes that have been made in 1.474+.

          cjo9900 added a comment - - edited

          digging a bit deeper into the generated element that is shown in the web ui, shows that the elements that the optionalBlock controls along with itself, do not have any ref or nameref attributes. Which is what I believe binds the elements together for conversion when submitting the config.

          from 1.473 the items are defined as

          <tr class="optional-block-start row-set-start" hashelp="true" ref="cb24">
              <input name="_.block" class=" " onclick="javascript:updateOptionalBlock(this,true)" type="checkbox" id="cb24">
          
              <tr nameref="cb24" style="display: none; ">
          ...
                  <td class="setting-main">
                  <select name="buildStepFailureThreshold" class="setting-input">
          ...
          <tr class="row-set-end rowvg-end optional-block-end">
          

          when seen from 1.477-SNAPSHOT (also in 1.474-6)

          <tr class="optional-block-start row-set-start" hashelp="true">
              <input name="_.block" class=" " onclick="javascript:updateOptionalBlock(this,true)" type="checkbox">
          
              <tr>
          ...
                  <td class="setting-main">
                  <select name="buildStepFailureThreshold" class="setting-input">
          ...
          <tr class="row-set-end rowvg-end optional-block-end">
          

          Looking elsewhere in the page the default TimerTrigger elements does have these ref elements defined.

          Hope this information is useful to someone who knows more about how these page fragments are created.

          Chris.

          cjo9900 added a comment - - edited digging a bit deeper into the generated element that is shown in the web ui, shows that the elements that the optionalBlock controls along with itself, do not have any ref or nameref attributes. Which is what I believe binds the elements together for conversion when submitting the config. from 1.473 the items are defined as <tr class= "optional-block-start row-set-start" hashelp= "true" ref= "cb24" > <input name= "_.block" class= " " onclick= "javascript:updateOptionalBlock(this,true)" type= "checkbox" id= "cb24" > <tr nameref= "cb24" style= "display: none; " > ... <td class= "setting-main" > <select name= "buildStepFailureThreshold" class= "setting-input" > ... <tr class= "row-set-end rowvg-end optional-block-end" > when seen from 1.477-SNAPSHOT (also in 1.474-6) <tr class= "optional-block-start row-set-start" hashelp= "true" > <input name= "_.block" class= " " onclick= "javascript:updateOptionalBlock(this,true)" type= "checkbox" > <tr> ... <td class= "setting-main" > <select name= "buildStepFailureThreshold" class= "setting-input" > ... <tr class= "row-set-end rowvg-end optional-block-end" > Looking elsewhere in the page the default TimerTrigger elements does have these ref elements defined. Hope this information is useful to someone who knows more about how these page fragments are created. Chris.

          cjo9900 added a comment - - edited

          From looking jenkins core it seems that the "TR.optional-block-start" from hudson-behaviour.js [1] is not being applied to the entries within the repeatable section.

          Which probably means that the rest of the elements are not correctly applied either.
          This includes the hetro-list that also don't populate after selection an item.

          [1] https://github.com/jenkinsci/jenkins/blob/96442cd9cd7b432a19d05dd945502a854541cae7/war/src/main/webapp/scripts/hudson-behavior.js#L852

          cjo9900 added a comment - - edited From looking jenkins core it seems that the "TR.optional-block-start" from hudson-behaviour.js [1] is not being applied to the entries within the repeatable section. Which probably means that the rest of the elements are not correctly applied either. This includes the hetro-list that also don't populate after selection an item. [1] https://github.com/jenkinsci/jenkins/blob/96442cd9cd7b432a19d05dd945502a854541cae7/war/src/main/webapp/scripts/hudson-behavior.js#L852

          cjo9900 added a comment -

          I think I have tracked the error down to the hetro list which in this case asserts because the prototypes variable, is undefined at this point
          https://github.com/jenkinsci/jenkins/blob/master/core/src/main/resources/lib/form/hetero-list/hetero-list.js#L17
          so calling previous() fails.

          Putting an if check in for prototypes == null and returning at that point, seems to allow the the page to load correctly and the configuration to be saved correctly.

          Not sure of the side affects as I am not a JS expert.

          cjo9900 added a comment - I think I have tracked the error down to the hetro list which in this case asserts because the prototypes variable, is undefined at this point https://github.com/jenkinsci/jenkins/blob/master/core/src/main/resources/lib/form/hetero-list/hetero-list.js#L17 so calling previous() fails. Putting an if check in for prototypes == null and returning at that point, seems to allow the the page to load correctly and the configuration to be saved correctly. Not sure of the side affects as I am not a JS expert.

          cjo9900 added a comment -

          The type error occurs with call stack pointing to the hetero-list.js, full call stack is in image
          JS_typeError_JENKINS-14495.png

          Looking back the stack we see this is invoked from the render event, this event is caused by the loading of the triggerbuilder descriptor elements.
          The outerHTML at that point is the data from the descriptor see gist [1]

          At the point of failure the element that was being processed has the following outerHTML

          <div class="hetero-list-container with-drag-drop one-each ">
            <div class="repeatable-insertion-point">
            </div>
            <div>
              <span class="yui-button yui-menu-button" id="yui-gen22">
                <span class="first-child">
                  <button type="button" tabindex="0" id="yui-gen22-button" class="hetero-list-add" suffix="configs">Add Parameters
                  </button>
                </span>
              </span>
            </div>
          </div>
          

          which seems to indicate that the element has already been processed once.
          looking at the registered behaviours, there are 10 elements in the list, including duplicate entries that are added by hetero-list.js and repeatable.js. see image JS_registered_Behaviours_JENKINS-14495.png (element [5] is from hudson-behaviour.js).

          so as Behaviour.applySubtree() runs over each item in the list some behaviours are getting run multiple times, which is causing the problem.

          [1] https://gist.github.com/3246770

          cjo9900 added a comment - The type error occurs with call stack pointing to the hetero-list.js, full call stack is in image JS_typeError_ JENKINS-14495 .png Looking back the stack we see this is invoked from the render event, this event is caused by the loading of the triggerbuilder descriptor elements. The outerHTML at that point is the data from the descriptor see gist [1] At the point of failure the element that was being processed has the following outerHTML <div class= "hetero-list-container with-drag-drop one-each " > <div class= "repeatable-insertion-point" > </div> <div> <span class= "yui-button yui-menu-button" id= "yui-gen22" > <span class= "first-child" > <button type= "button" tabindex= "0" id= "yui-gen22-button" class= "hetero-list-add" suffix= "configs" > Add Parameters </button> </span> </span> </div> </div> which seems to indicate that the element has already been processed once. looking at the registered behaviours, there are 10 elements in the list, including duplicate entries that are added by hetero-list.js and repeatable.js. see image JS_registered_Behaviours_ JENKINS-14495 .png (element [5] is from hudson-behaviour.js). so as Behaviour.applySubtree() runs over each item in the list some behaviours are getting run multiple times, which is causing the problem. [1] https://gist.github.com/3246770

          Jesse Glick added a comment -

          I think you are getting at the crux of the problem when you find that there are duplicates in registered behaviors. My fix of JENKINS-14514 was just a blind workaround for that, and it seems like pull #533 is very similar. My guess is that splitting JavaScript into separate files resulted in behavior registration being run repeatedly from the same <st:adjunct/>, and apparently this was not idempotent. Will look deeper.

          Jesse Glick added a comment - I think you are getting at the crux of the problem when you find that there are duplicates in registered behaviors. My fix of JENKINS-14514 was just a blind workaround for that, and it seems like pull #533 is very similar. My guess is that splitting JavaScript into separate files resulted in behavior registration being run repeatedly from the same <st:adjunct/> , and apparently this was not idempotent. Will look deeper.

          Code changed in jenkins
          User: Jesse Glick
          Path:
          changelog.html
          core/src/main/resources/lib/form/repeatable/repeatable.js
          war/src/main/webapp/scripts/behavior.js
          http://jenkins-ci.org/commit/jenkins/dbb100da58a084fb0a6ce129d3f2b7ad827e87ee
          Log:
          [FIXED JENKINS-14495] Hetero lists not working correctly after adding elements.
          Unlike JENKINS-14514 this is a true fix rather than a workaround (now removed), and is more general.
          cjo9900 discovered that behaviors were being redundantly registered (as of 1.474 the monolithic JS is broken up);
          this caused some behaviors to be run repeatedly on the same elements, breaking reasonable expectations of some behaviors.
          The ideal fix would be to change Behavior.register to be idempotent: for example, key it by selector, then maintain a set of distinct behavior functions for each.
          Unfortunately some adjuncts directly call Behavior.list.unshift, bypassing register(...), which would be tricky to intercept (would need to make a mock of Array).
          The known one cases are in core, but it is possible plugin adjuncts do this too, in which case it would be incompatible to (say) change the Array<Map<String,Behavior>> to a Map<String,Array<Behavior>>.
          Instead, permitting redundant registrations as before, and just silently skipping all but the first at runtime when applying behaviors.
          Beware that since adjuncts are loaded from multiple places, different JS function objects are registered each time, so a naive set of behavior functions does not work;
          have to identify functions by their toString in order to ensure that each is run only once.
          (Currently once per selector, conceivably >1x per element; could if necessary be refined to make sure a given behavior is only run once on a given element during one call to applySubtree even if the element matches multiple selectors.)

          SCM/JIRA link daemon added a comment - Code changed in jenkins User: Jesse Glick Path: changelog.html core/src/main/resources/lib/form/repeatable/repeatable.js war/src/main/webapp/scripts/behavior.js http://jenkins-ci.org/commit/jenkins/dbb100da58a084fb0a6ce129d3f2b7ad827e87ee Log: [FIXED JENKINS-14495] Hetero lists not working correctly after adding elements. Unlike JENKINS-14514 this is a true fix rather than a workaround (now removed), and is more general. cjo9900 discovered that behaviors were being redundantly registered (as of 1.474 the monolithic JS is broken up); this caused some behaviors to be run repeatedly on the same elements, breaking reasonable expectations of some behaviors. The ideal fix would be to change Behavior.register to be idempotent: for example, key it by selector, then maintain a set of distinct behavior functions for each. Unfortunately some adjuncts directly call Behavior.list.unshift, bypassing register(...), which would be tricky to intercept (would need to make a mock of Array). The known one cases are in core, but it is possible plugin adjuncts do this too, in which case it would be incompatible to (say) change the Array<Map<String,Behavior>> to a Map<String,Array<Behavior>>. Instead, permitting redundant registrations as before, and just silently skipping all but the first at runtime when applying behaviors. Beware that since adjuncts are loaded from multiple places, different JS function objects are registered each time, so a naive set of behavior functions does not work; have to identify functions by their toString in order to ensure that each is run only once. (Currently once per selector , conceivably >1x per element; could if necessary be refined to make sure a given behavior is only run once on a given element during one call to applySubtree even if the element matches multiple selectors.)

          dogfood added a comment -

          Integrated in jenkins_main_trunk #1834
          [FIXED JENKINS-14495] Hetero lists not working correctly after adding elements. (Revision dbb100da58a084fb0a6ce129d3f2b7ad827e87ee)

          Result = UNSTABLE
          Jesse Glick : dbb100da58a084fb0a6ce129d3f2b7ad827e87ee
          Files :

          • core/src/main/resources/lib/form/repeatable/repeatable.js
          • changelog.html
          • war/src/main/webapp/scripts/behavior.js

          dogfood added a comment - Integrated in jenkins_main_trunk #1834 [FIXED JENKINS-14495] Hetero lists not working correctly after adding elements. (Revision dbb100da58a084fb0a6ce129d3f2b7ad827e87ee) Result = UNSTABLE Jesse Glick : dbb100da58a084fb0a6ce129d3f2b7ad827e87ee Files : core/src/main/resources/lib/form/repeatable/repeatable.js changelog.html war/src/main/webapp/scripts/behavior.js

          Jesse Glick added a comment -

          Looks like my change caused a couple of test failures, investigating...

          Jesse Glick added a comment - Looks like my change caused a couple of test failures, investigating...

          Code changed in jenkins
          User: Jesse Glick
          Path:
          test/src/test/java/scripts/BehaviorTest.java
          test/src/test/resources/scripts/BehaviorTest/testDuplicateRegistrations.jelly
          war/src/main/webapp/scripts/behavior.js
          http://jenkins-ci.org/commit/jenkins/f39fbdb312c3c87ef77a72446273423d906942ed
          Log:
          JENKINS-14495 Refined fix - needed to pull uniqueness check out of apply() fn in case we were being passed an Array of nodes.
          Fixes test failures introduced by dbb100d, and adds a test for it now that I know it can be done.

          SCM/JIRA link daemon added a comment - Code changed in jenkins User: Jesse Glick Path: test/src/test/java/scripts/BehaviorTest.java test/src/test/resources/scripts/BehaviorTest/testDuplicateRegistrations.jelly war/src/main/webapp/scripts/behavior.js http://jenkins-ci.org/commit/jenkins/f39fbdb312c3c87ef77a72446273423d906942ed Log: JENKINS-14495 Refined fix - needed to pull uniqueness check out of apply() fn in case we were being passed an Array of nodes. Fixes test failures introduced by dbb100d, and adds a test for it now that I know it can be done.

          dogfood added a comment -

          Integrated in jenkins_main_trunk #1835
          JENKINS-14495 Refined fix - needed to pull uniqueness check out of apply() fn in case we were being passed an Array of nodes. (Revision f39fbdb312c3c87ef77a72446273423d906942ed)

          Result = SUCCESS
          Jesse Glick : f39fbdb312c3c87ef77a72446273423d906942ed
          Files :

          • test/src/test/resources/scripts/BehaviorTest/testDuplicateRegistrations.jelly
          • test/src/test/java/scripts/BehaviorTest.java
          • war/src/main/webapp/scripts/behavior.js

          dogfood added a comment - Integrated in jenkins_main_trunk #1835 JENKINS-14495 Refined fix - needed to pull uniqueness check out of apply() fn in case we were being passed an Array of nodes. (Revision f39fbdb312c3c87ef77a72446273423d906942ed) Result = SUCCESS Jesse Glick : f39fbdb312c3c87ef77a72446273423d906942ed Files : test/src/test/resources/scripts/BehaviorTest/testDuplicateRegistrations.jelly test/src/test/java/scripts/BehaviorTest.java war/src/main/webapp/scripts/behavior.js

          Code changed in jenkins
          User: Jesse Glick
          Path:
          changelog.html
          http://jenkins-ci.org/commit/jenkins/9c016d61a0b5972f1c84b7137a0bce031ac80c17
          Log:
          JENKINS-14495 Noting further changes.

          SCM/JIRA link daemon added a comment - Code changed in jenkins User: Jesse Glick Path: changelog.html http://jenkins-ci.org/commit/jenkins/9c016d61a0b5972f1c84b7137a0bce031ac80c17 Log: JENKINS-14495 Noting further changes.

          Code changed in jenkins
          User: Jesse Glick
          Path:
          changelog.html
          core/src/main/resources/hudson/PluginManager/_table.js
          core/src/main/resources/hudson/console/ExpandableDetailsNote/script.js
          core/src/main/resources/hudson/matrix/LabelAxis/config.jelly
          core/src/main/resources/hudson/security/GlobalMatrixAuthorizationStrategy/config.jelly
          core/src/main/resources/lib/form/advanced/advanced.js
          core/src/main/resources/lib/form/apply/apply.js
          core/src/main/resources/lib/form/combobox/combobox.js
          core/src/main/resources/lib/form/hetero-list/hetero-list.js
          core/src/main/resources/lib/form/radioBlock/radioBlock.js
          core/src/main/resources/lib/form/repeatable/repeatable.js
          core/src/main/resources/lib/form/select/select.js
          core/src/main/resources/lib/form/textarea/textarea.js
          core/src/main/resources/lib/hudson/projectViewNested.js
          core/src/main/resources/lib/layout/breadcrumbs.js
          core/src/main/resources/lib/layout/copyButton/copyButton.js
          test/src/test/java/scripts/BehaviorTest.java
          test/src/test/resources/lib/layout/RenderOnDemandTest/testBehaviour.jelly
          test/src/test/resources/scripts/BehaviorTest/testDuplicateRegistrations.jelly
          test/src/test/resources/scripts/BehaviorTest/testSelectorOrdering.jelly
          ui-samples-plugin/src/main/resources/jenkins/plugins/ui_samples/SyntaxHighlightedTextArea/index.groovy
          war/src/main/webapp/scripts/behavior.js
          war/src/main/webapp/scripts/hudson-behavior.js
          http://jenkins-ci.org/commit/jenkins/3b1c38675357706d982c804971193f5a2df8eff4
          Log:
          Merge pull request #545 from jglick/Behaviour-specify-14495

          JENKINS-14495 Define Behaviour.specify.

          Compare: https://github.com/jenkinsci/jenkins/compare/c733b24be79d...3b1c38675357

          SCM/JIRA link daemon added a comment - Code changed in jenkins User: Jesse Glick Path: changelog.html core/src/main/resources/hudson/PluginManager/_table.js core/src/main/resources/hudson/console/ExpandableDetailsNote/script.js core/src/main/resources/hudson/matrix/LabelAxis/config.jelly core/src/main/resources/hudson/security/GlobalMatrixAuthorizationStrategy/config.jelly core/src/main/resources/lib/form/advanced/advanced.js core/src/main/resources/lib/form/apply/apply.js core/src/main/resources/lib/form/combobox/combobox.js core/src/main/resources/lib/form/hetero-list/hetero-list.js core/src/main/resources/lib/form/radioBlock/radioBlock.js core/src/main/resources/lib/form/repeatable/repeatable.js core/src/main/resources/lib/form/select/select.js core/src/main/resources/lib/form/textarea/textarea.js core/src/main/resources/lib/hudson/projectViewNested.js core/src/main/resources/lib/layout/breadcrumbs.js core/src/main/resources/lib/layout/copyButton/copyButton.js test/src/test/java/scripts/BehaviorTest.java test/src/test/resources/lib/layout/RenderOnDemandTest/testBehaviour.jelly test/src/test/resources/scripts/BehaviorTest/testDuplicateRegistrations.jelly test/src/test/resources/scripts/BehaviorTest/testSelectorOrdering.jelly ui-samples-plugin/src/main/resources/jenkins/plugins/ui_samples/SyntaxHighlightedTextArea/index.groovy war/src/main/webapp/scripts/behavior.js war/src/main/webapp/scripts/hudson-behavior.js http://jenkins-ci.org/commit/jenkins/3b1c38675357706d982c804971193f5a2df8eff4 Log: Merge pull request #545 from jglick/Behaviour-specify-14495 JENKINS-14495 Define Behaviour.specify. Compare: https://github.com/jenkinsci/jenkins/compare/c733b24be79d...3b1c38675357

          dogfood added a comment -

          Integrated in jenkins_main_trunk #1871
          JENKINS-14495 Noting further changes. (Revision 9c016d61a0b5972f1c84b7137a0bce031ac80c17)

          Result = UNSTABLE
          Jesse Glick : 9c016d61a0b5972f1c84b7137a0bce031ac80c17
          Files :

          • changelog.html

          dogfood added a comment - Integrated in jenkins_main_trunk #1871 JENKINS-14495 Noting further changes. (Revision 9c016d61a0b5972f1c84b7137a0bce031ac80c17) Result = UNSTABLE Jesse Glick : 9c016d61a0b5972f1c84b7137a0bce031ac80c17 Files : changelog.html

            jglick Jesse Glick
            romu Romu Hu
            Votes:
            4 Vote for this issue
            Watchers:
            17 Start watching this issue

              Created:
              Updated:
              Resolved: