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

Sharable Libraries class loader "Grabs" to different class loader

    XMLWordPrintable

    Details

    • Similar Issues:

      Description

      I have a shared library class I am trying to execute in a jenkins pipeline.  In the shared libraries doc it says you can "Grab" an artifact from a maven repo and load it into your classpath.  In this case I'm pulling amazon's java sdk so that I can make some calls to describe our AMIs.  The groovy class in the shared library works fine if I run it on my local dev box via command line.  When I upload it to the shared library and try to execute it through a jenkins pipeline, I get the error below.

      hudson.remoting.ProxyException: groovy.lang.MissingMethodException: No signature of method: com.amazonaws.services.ec2.AmazonEC2Client.describeImages() is applicable for argument types: (com.amazonaws.services.ec2.model.DescribeImagesRequest) values: [{ImageIds: [],Owners: [],ExecutableUsers: [],Filters: [{Name: tag:Name,Values: [Convert Rets Base Image]}]}]
      Possible solutions: describeImages(), describeImages(com.amazonaws.services.ec2.model.DescribeImagesRequest), describeTags(), describeTags(com.amazonaws.services.ec2.model.DescribeTagsRequest)
      The following classes appear as argument class and as parameter class, but are defined by different class loader:
      com.amazonaws.services.ec2.model.DescribeImagesRequest (defined by 'AntClassLoader
      ...
      If one of the method suggestions matches the method you wanted to call,
      then check your class loader setup.
      ...

      I've included the pipeline I'm using, the console output of the build, and the groovy script I'm calling in the shared library.  I haven't been able to find anything online and it looks like I'm doing everything the documentation says I should be doing.  I'm hoping I just misconfigured something but I'm thinking there may be a bug somewhere.

        Attachments

        1. BuildConsoleOutput
          24 kB
        2. DescribeImages.groovy
          2 kB
        3. Pipeline
          0.3 kB

          Activity

          Hide
          cjmead Corey Mead added a comment - - edited

          Dropped it down to minor because I was able to resolve the issue using ubuntu linux instead of amazon linux.  Using the amazon linux master didn't work but I replicated the same scenario with a ubuntu master and found it worked, so maybe this is related to something in the OS?  In any case, I've got a work around that I can live with.

          Show
          cjmead Corey Mead added a comment - - edited Dropped it down to minor because I was able to resolve the issue using ubuntu linux instead of amazon linux.  Using the amazon linux master didn't work but I replicated the same scenario with a ubuntu master and found it worked, so maybe this is related to something in the OS?  In any case, I've got a work around that I can live with.
          Hide
          stsojithomas Soji Thomas added a comment -

          I think this is a major issue. Your workaround works only for the time-being and is very unpredictable. The workaround could stop working once you upgrade to the next version of Ubuntu. 

           

          Ideally, shared libraries execution should be isolated to the dependencies supplied with the shared library and not dependent on libraries that come with Jenkins. In our case, we depend on commons-beanutils 1.9.3 while Jenkins (war) comes packaged with commons-beanutils 1.8.3, which is loaded before the version we need, causing our shared library to fail execution.

          Show
          stsojithomas Soji Thomas added a comment - I think this is a major issue. Your workaround works only for the time-being and is very unpredictable. The workaround could stop working once you upgrade to the next version of Ubuntu.    Ideally, shared libraries execution should be isolated to the dependencies supplied with the shared library and not dependent on libraries that come with Jenkins. In our case, we depend on commons-beanutils 1.9.3 while Jenkins (war) comes packaged with commons-beanutils 1.8.3, which is loaded before the version we need, causing our shared library to fail execution.
          Hide
          iponomarev Ivan Ponomarev added a comment - - edited

          Another example:

          @Grab('org.asciidoctor:asciidoctorj:1.5.8.1')
          import org.asciidoctor.Asciidoctor
          

          AsciiDoctorJ has transitive dependency from

          org.jruby:jruby-complete:9.1.17.0
          

          However, when I do

          import org.jruby.Ruby
          echo Ruby.globalRuntime.evalScriptlet("JRUBY_VERSION").toString()
          

          I see 1.7.3 (no idea where it came from).

          And this is why I cannot use asciidoctorj:1.5.6 (I get
          `java.lang.NoSuchMethodError: org.jruby.RubyModule.getMethodLocation()Lorg/jruby/RubyModule;`
          during initialization: indeed, no such method in JRuby 1.7.3)

          Show
          iponomarev Ivan Ponomarev added a comment - - edited Another example: @Grab( 'org.asciidoctor:asciidoctorj:1.5.8.1' ) import org.asciidoctor.Asciidoctor AsciiDoctorJ has transitive dependency from org.jruby:jruby-complete:9.1.17.0 However, when I do import org.jruby.Ruby echo Ruby.globalRuntime.evalScriptlet( "JRUBY_VERSION" ).toString() I see 1.7.3 (no idea where it came from). And this is why I cannot use asciidoctorj:1.5.6 (I get `java.lang.NoSuchMethodError: org.jruby.RubyModule.getMethodLocation()Lorg/jruby/RubyModule;` during initialization: indeed, no such method in JRuby 1.7.3)

            People

            • Assignee:
              Unassigned
              Reporter:
              cjmead Corey Mead
            • Votes:
              3 Vote for this issue
              Watchers:
              5 Start watching this issue

              Dates

              • Created:
                Updated: