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

Java 11 Docker Image: Invalid Manifest format when loading Git Client Plugin 2.7.2, JDK 11ea+18 is required

    • Icon: Bug Bug
    • Resolution: Fixed
    • Icon: Critical Critical
    • docker
    • Java 11 preview

      When running on Java 11, some plugins fail to startup with the following error:

      INFO: Winstone Servlet Engine v4.0 running: controlPort=disabled
      Jun 11, 2018 10:01:07 PM jenkins.InitReactorRunner$1 onAttained
      INFO: Started initialization
      Jun 11, 2018 10:01:07 PM jenkins.InitReactorRunner$1 onTaskFailed
      SEVERE: Failed Inspecting plugin /Users/nenashev/Documents/jenkins/test/java10/work/plugins/git-client.jpi
      java.io.IOException: invalid manifest format
      	at java.base/java.util.jar.Manifest.read(Manifest.java:223)
      	at java.base/java.util.jar.Manifest.<init>(Manifest.java:69)
      	at java.base/java.util.jar.JarFile.getManifestFromReference(JarFile.java:416)
      	at java.base/java.util.jar.JarFile.getManifest(JarFile.java:402)
      	at jenkins.util.AntClassLoader.addPathFile(AntClassLoader.java:504)
      	at jenkins.util.AntWithFindResourceClassLoader.addPathFiles(AntWithFindResourceClassLoader.java:35)
      	at hudson.ClassicPluginStrategy.createClassLoader(ClassicPluginStrategy.java:317)
      	at hudson.ClassicPluginStrategy.createPluginWrapper(ClassicPluginStrategy.java:258)
      	at hudson.PluginManager$1$3$1.run(PluginManager.java:403)
      	at org.jvnet.hudson.reactor.TaskGraphBuilder$TaskImpl.run(TaskGraphBuilder.java:169)
      	at org.jvnet.hudson.reactor.Reactor.runTask(Reactor.java:296)
      	at jenkins.model.Jenkins$5.runTask(Jenkins.java:1068)
      	at org.jvnet.hudson.reactor.Reactor$2.run(Reactor.java:214)
      	at org.jvnet.hudson.reactor.Reactor$Node.run(Reactor.java:117)
      	at java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128)
      	at java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628)
      	at java.base/java.lang.Thread.run(Thread.java:832)
      
      
      

          [JENKINS-51871] Java 11 Docker Image: Invalid Manifest format when loading Git Client Plugin 2.7.2, JDK 11ea+18 is required

          Devin Nusbaum added a comment -

          I was unable to reproduce this locally running the java11-support branch locally with Java build 11-ea+18. My best guess is that there was an error in a SHA (maybe a corrupted download?), but I would have expected that to be caught earlier in the installation process, so I'm not sure. oleg_nenashev are you still able to reproduce the issue?

          Devin Nusbaum added a comment - I was unable to reproduce this locally running the java11-support branch locally with Java build 11-ea+18. My best guess is that there was an error in a SHA (maybe a corrupted download?), but I would have expected that to be caught earlier in the installation process, so I'm not sure. oleg_nenashev are you still able to reproduce the issue?

          Oleg Nenashev added a comment -

          dnusbaum yes, I am still able to reproduce it in Docker

          1) Run docker run -p 8080:8080 -p 50000:50000 jenkins/jenkins-experimental:latest-jdk11
          2) Select "Git plugin" in the installation wizard

          Oleg Nenashev added a comment - dnusbaum yes, I am still able to reproduce it in Docker 1) Run docker run -p 8080:8080 -p 50000:50000 jenkins/jenkins-experimental:latest-jdk11 2) Select "Git plugin" in the installation wizard

          Oleg Nenashev added a comment -

          https://github.com/jenkinsci/jenkins/pull/3505 will change the image tho. Maybe it makes sense to try again once it's merged

          Oleg Nenashev added a comment - https://github.com/jenkinsci/jenkins/pull/3505 will change the image tho. Maybe it makes sense to try again once it's merged

          Devin Nusbaum added a comment -

          oleg_nenashev Ok, my local version is based on `jdk-11-ea+18`, but the docker images look like they are based on `jdk-11-ea+17`, so maybe that is related. I will investigate further.

          Devin Nusbaum added a comment - oleg_nenashev Ok, my local version is based on `jdk-11-ea+18`, but the docker images look like they are based on `jdk-11-ea+17`, so maybe that is related. I will investigate further.

          Oleg Nenashev added a comment -

          Thanks! If it's related, I will rebuild the image tomorrow

          Oleg Nenashev added a comment - Thanks! If it's related, I will rebuild the image tomorrow

          Oleg Nenashev added a comment -

          dnusbaum jdk-11-ea+18 has not been pushed to Docker yet, so I cannot verify the theory.
          According to http://jdk.java.net/11/release-notes the build just adds GoDaddy certificates so there should be no relation

          Oleg Nenashev added a comment - dnusbaum jdk-11-ea+18 has not been pushed to Docker yet, so I cannot verify the theory. According to http://jdk.java.net/11/release-notes the build just adds GoDaddy certificates so there should be no relation

          Devin Nusbaum added a comment -

          Looks like the release notes are only notable changes. I looked through the history of Manifest.java, and saw this change in 11 build 17: https://bugs.openjdk.java.net/browse/JDK-8200530, which caused a regression which was fixed in 11 build 18: https://bugs.openjdk.java.net/browse/JDK-8204494. I will install build 17 locally to confirm that I can reproduce.

          Devin Nusbaum added a comment - Looks like the release notes are only notable changes. I looked through the history of Manifest.java, and saw this change in 11 build 17: https://bugs.openjdk.java.net/browse/JDK-8200530 , which caused a regression which was fixed in 11 build 18: https://bugs.openjdk.java.net/browse/JDK-8204494 . I will install build 17 locally to confirm that I can reproduce.

          Devin Nusbaum added a comment -

          Confirmed locally as specific to JDK 11ea+17 (likely caused by JDK-8200530) and fixed in JDK 11ea+18 (likely fixed by JDK-8204494). There is nothing we need to do other than update our Docker images once the JDK 11ea+18 Docker image is available.

          Devin Nusbaum added a comment - Confirmed locally as specific to JDK 11ea+17 (likely caused by JDK-8200530 ) and fixed in JDK 11ea+18 (likely fixed by JDK-8204494 ). There is nothing we need to do other than update our Docker images once the JDK 11ea+18 Docker image is available.

          Oleg Nenashev added a comment -

          Thanks dnusbaum! I will reopen it and recategorize as a Docker image defect

          Oleg Nenashev added a comment - Thanks dnusbaum ! I will reopen it and recategorize as a Docker image defect

          Oleg Nenashev added a comment - - edited

          It was fixed in new Docker image versions

          Oleg Nenashev added a comment - - edited It was fixed in new Docker image versions

            oleg_nenashev Oleg Nenashev
            oleg_nenashev Oleg Nenashev
            Votes:
            0 Vote for this issue
            Watchers:
            3 Start watching this issue

              Created:
              Updated:
              Resolved: