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

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

    XMLWordPrintable

    Details

    • Type: Bug
    • Status: Resolved (View Workflow)
    • Priority: Major
    • Resolution: Fixed
    • Labels:
      None
    • Environment:
      CentOS 6 x86_64, jre-1.7.0_04-fcs.x86_64, Jenkins 1.474, Parameterized trigger plugin 2.15
    • Similar Issues:

      Description

      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

        Attachments

          Issue Links

            Activity

            Hide
            ffromm 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.

            Show
            ffromm 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.
            Hide
            hombrefab 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

            Show
            hombrefab 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
            Hide
            tificsor Tibor Ficsor added a comment -

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

            Show
            tificsor Tibor Ficsor added a comment - Same here, please share workaround if available. (Jenkins 1.474, Parameterized trigger plugin 2.15)
            Hide
            donatello Stephan Grimm added a comment -

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

            Show
            donatello Stephan Grimm added a comment - It works after downgrading to Jenkins 1.471 and Parameterized Trigger Plugin 2.14.
            Hide
            shawnmjones 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.

            Show
            shawnmjones 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.
            Hide
            cjo9900 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>
            
            Show
            cjo9900 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>
            Hide
            owenmehegan Owen Mehegan added a comment -

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

            Show
            owenmehegan Owen Mehegan added a comment - Argh, this is hitting me too, and I use Parameterized Trigger all over the place
            Hide
            cjo9900 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+.

            Show
            cjo9900 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+.
            Hide
            cjo9900 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.

            Show
            cjo9900 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.
            Hide
            cjo9900 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

            Show
            cjo9900 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
            Hide
            cjo9900 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.

            Show
            cjo9900 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.
            Hide
            cjo9900 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

            Show
            cjo9900 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
            Hide
            jglick 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.

            Show
            jglick 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.
            Hide
            scm_issue_link 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.)

            Show
            scm_issue_link 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.)
            Hide
            dogfood 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
            Show
            dogfood 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
            Hide
            jglick Jesse Glick added a comment -

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

            Show
            jglick Jesse Glick added a comment - Looks like my change caused a couple of test failures, investigating...
            Hide
            scm_issue_link 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.

            Show
            scm_issue_link 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.
            Hide
            dogfood 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
            Show
            dogfood 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
            Hide
            scm_issue_link 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.

            Show
            scm_issue_link 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.
            Hide
            scm_issue_link 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

            Show
            scm_issue_link 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
            Hide
            dogfood 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
            Show
            dogfood 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

              People

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

                Dates

                Created:
                Updated:
                Resolved: