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

java.lang.NoSuchMethodError on OSX

    Details

    • Type: Bug
    • Status: Closed (View Workflow)
    • Priority: Major
    • Resolution: Not A Defect
    • Component/s: gerrit-trigger-plugin
    • Labels:
    • Environment:
    • Similar Issues:

      Description

      I'm developing a plugin (https://github.com/zaro0508/verify-status-reporter) on my MAC. When I debug and run this plugin using hpi:run it works fine. When I run jenkins with `java -jar jenkins.war` install the plugin then I get a runtime error (java.lang.NoSuchMethodError). This error happens on my MAC. However when I run it the exact same way on Ubuntu Xenial `java -jar jenkins.war` then it work fine. I think there's something screwy with the classloading on OSX.

      I notice the error will not happen if I depend on the Jenkins plugin parent pom ver 1.580.1 but when I switch to ver 2.7 to match the Gerrit trigger plugin the problem happens. The dependency is looks like this..

      <parent>
      <groupId>org.jenkins-ci.plugins</groupId>
      <artifactId>plugin</artifactId>
      <version>2.7</version>
      <relativePath />
      </parent>

      here is the stack trace..

      INFO: All Builds are completed for cause: GerritCause: com.sonymobile.tools.gerrit.gerritevents.dto.events.CommentAdded@704e521 silent: false
      Sep 02, 2016 10:49:23 AM hudson.model.AbstractBuild$AbstractBuildExecution reportError
      WARNING: Step ‘Post Verification to Gerrit’ aborted due to exception:
      java.lang.NoSuchMethodError: com.google.gerrit.extensions.api.changes.RevisionApi.verifyStatus()Lcom/google/gerrit/extensions/api/changes/VerifyStatusApi;
      at org.jenkinsci.plugins.verifystatus.VerificationsPublisher.perform(VerificationsPublisher.java:174)
      at hudson.tasks.BuildStepMonitor$1.perform(BuildStepMonitor.java:20)
      at hudson.model.AbstractBuild$AbstractBuildExecution.perform(AbstractBuild.java:785)
      at hudson.model.AbstractBuild$AbstractBuildExecution.performAllBuildSteps(AbstractBuild.java:726)
      at hudson.model.Build$BuildExecution.cleanUp(Build.java:195)
      at hudson.model.Run.execute(Run.java:1788)
      at hudson.model.FreeStyleBuild.run(FreeStyleBuild.java:43)
      at hudson.model.ResourceController.execute(ResourceController.java:98)
      at hudson.model.Executor.run(Executor.java:408)

        Attachments

          Activity

          Hide
          bitwiseman Liam Newman added a comment - - edited

          We just walked through this on IRC, but I'll comment to make sure it is documented.

          This isn't a jenkins bug, sorry. This is class load ordering issue.
          http://stackoverflow.com/questions/18922463/controlling-the-loading-of-java-class-in-classpath

          Your project depends on https://github.com/uwolfer/gerrit-rest-java-client, but then also re-implements classes and interfaces that are are in that library.

          See:
          https://github.com/uwolfer/gerrit-rest-java-client/blob/master/src/main/java/com/google/gerrit/extensions/api/changes/RevisionApi.java
          https://github.com/zaro0508/verify-status-reporter/blob/41bc30574f09b0e95d72685534e45d063c98900e/src/main/java/com/google/gerrit/extensions/api/changes/RevisionApi.java#L41

          Depending on if your class or the library class is loaded first, your plugin will work or throw this exception. Further, other plugins that use the same library may also fail due to them using your classes instead of the ones from the library.

          You should implement your own classes that extend/inherit from the gerrit-rest-java-client classes.

          The key point being that you absolutely should never have classes with the same fully qualified name ("com.google.gerrit.extensions.api.changes.RevisionApi", for example) in two different jars that might ever be loaded into one JVM, or more specifically by loaded by the same ClassLoader.

          Show
          bitwiseman Liam Newman added a comment - - edited We just walked through this on IRC, but I'll comment to make sure it is documented. This isn't a jenkins bug, sorry. This is class load ordering issue. http://stackoverflow.com/questions/18922463/controlling-the-loading-of-java-class-in-classpath Your project depends on https://github.com/uwolfer/gerrit-rest-java-client , but then also re-implements classes and interfaces that are are in that library. See: https://github.com/uwolfer/gerrit-rest-java-client/blob/master/src/main/java/com/google/gerrit/extensions/api/changes/RevisionApi.java https://github.com/zaro0508/verify-status-reporter/blob/41bc30574f09b0e95d72685534e45d063c98900e/src/main/java/com/google/gerrit/extensions/api/changes/RevisionApi.java#L41 Depending on if your class or the library class is loaded first, your plugin will work or throw this exception. Further, other plugins that use the same library may also fail due to them using your classes instead of the ones from the library. You should implement your own classes that extend/inherit from the gerrit-rest-java-client classes. The key point being that you absolutely should never have classes with the same fully qualified name ("com.google.gerrit.extensions.api.changes.RevisionApi", for example) in two different jars that might ever be loaded into one JVM, or more specifically by loaded by the same ClassLoader.
          Hide
          zaro0508 Khai Do added a comment -

          Thank you. Having classloader luck is such a curse!

          Show
          zaro0508 Khai Do added a comment - Thank you. Having classloader luck is such a curse!

            People

            • Assignee:
              rsandell rsandell
              Reporter:
              zaro0508 Khai Do
            • Votes:
              0 Vote for this issue
              Watchers:
              2 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved: