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

Sharable Libraries class loader "Grabs" to different class loader

      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.

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

          [JENKINS-44079] Sharable Libraries class loader "Grabs" to different class loader

          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.

          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.

          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.

          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.

          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)

          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)

          Hi, 
          I have the same problem trying to @Grab jackson-databind lib with version > 2.9 .
          I noticed that in the first environment everything works well but in the second environment ,using the same configuration, a different version of the library is loaded.
          The version loaded was used by the allure-plugin , if I remove that plugin the shared library works again.

          Hope this comment will help in order to solve the issue.

           

           

          Claudio Sturiale added a comment - Hi,  I have the same problem trying to @Grab jackson-databind lib with version > 2.9 . I noticed that in the first environment everything works well but in the second environment ,using the same configuration, a different version of the library is loaded. The version loaded was used by the allure-plugin , if I remove that plugin the shared library works again. Hope this comment will help in order to solve the issue.    

            Unassigned Unassigned
            cjmead Corey Mead
            Votes:
            4 Vote for this issue
            Watchers:
            7 Start watching this issue

              Created:
              Updated: