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

ConcurrentModificationException in DSL plugin 1.2.6

    • Icon: Bug Bug
    • Resolution: Unresolved
    • Icon: Major Major
    • job-dsl-plugin
    • None
    • OS X 10.9.4

      I upgraded the plugin to the newest version 1.2.6 and the jobs would no longer run and threw a ConcurrentModificationException every time I tried to run them. Log is attached.

          [JENKINS-25051] ConcurrentModificationException in DSL plugin 1.2.6

          The seems to be a similary issue as JENKINS-22708, but only for views.

          Can you check that your configure blocks for views are escaping calls to properties? Have a look at 4th bullet point on https://github.com/jenkinsci/job-dsl-plugin/wiki/The-Configure-Block#transforming-xml.

          Daniel Spilker added a comment - The seems to be a similary issue as JENKINS-22708 , but only for views. Can you check that your configure blocks for views are escaping calls to properties? Have a look at 4th bullet point on https://github.com/jenkinsci/job-dsl-plugin/wiki/The-Configure-Block#transforming-xml .

          Jeff Storey added a comment - - edited

          So I had previously added my own configure block to turn this parameter on before it was supported in the DSL with a block that looks like the following. When I replaced that with the new startsWithParameters block it worked.

          jobFactory.view(type: 'BuildPipelineView') {
              name("myPipeline")
              showPipelineParameters true
              showPipelineParametersInHeaders false
              showPipelineDefinitionHeader true
          			
              selectedJob("ajob")
              configure { pipelineNode ->
          	pipelineNode << {
          	    startsWithParameters true
                  }
             }
          }
          

          Jeff Storey added a comment - - edited So I had previously added my own configure block to turn this parameter on before it was supported in the DSL with a block that looks like the following. When I replaced that with the new startsWithParameters block it worked. jobFactory.view(type: 'BuildPipelineView' ) { name( "myPipeline" ) showPipelineParameters true showPipelineParametersInHeaders false showPipelineDefinitionHeader true selectedJob( "ajob" ) configure { pipelineNode -> pipelineNode << { startsWithParameters true } } }

          The problem is that startsWithParameters calls the new startsWithParameters method of BuildPipelineView which then internally adds a new WithXmlAction and that causes the ConcurrentModificationException.

          To avoid this, the startsWithParameters element name in the configure block should be quoted:

          ...
              configure { pipelineNode ->
                  pipelineNode << {
                      'startsWithParameters'(true)
                  }
              }
          ...
          

          This will happen for other element names when a method with the same name exists in the scope. I'm not sure if changing the closures resolution strategy will help or break other things.

          Daniel Spilker added a comment - The problem is that startsWithParameters calls the new startsWithParameters method of BuildPipelineView which then internally adds a new WithXmlAction and that causes the ConcurrentModificationException. To avoid this, the startsWithParameters element name in the configure block should be quoted: ... configure { pipelineNode -> pipelineNode << { 'startsWithParameters' ( true ) } } ... This will happen for other element names when a method with the same name exists in the scope. I'm not sure if changing the closures resolution strategy will help or break other things.

          I reduced the priority since there is a workaround.

          Daniel Spilker added a comment - I reduced the priority since there is a workaround.

          Jeff Storey added a comment -

          Thanks for looking into this so quickly. Agree that it is no longer a blocker. An alternative fix is to just upgrade to the new method. Though quoting it would ensure it works on older versions too. I understand your concerns about not necessarily wanting to change the closure strategy for this as this is probably an edge case. Feel free to close as won't fix since there is a reasonably easy workaround.

          Jeff Storey added a comment - Thanks for looking into this so quickly. Agree that it is no longer a blocker. An alternative fix is to just upgrade to the new method. Though quoting it would ensure it works on older versions too. I understand your concerns about not necessarily wanting to change the closure strategy for this as this is probably an edge case. Feel free to close as won't fix since there is a reasonably easy workaround.

            jamietanna Jamie Tanna
            jeffastorey Jeff Storey
            Votes:
            0 Vote for this issue
            Watchers:
            2 Start watching this issue

              Created:
              Updated: