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

NoClassDefFoundError on Base64 when launching an headless slave with -jnlpCredential option

    • Icon: Bug Bug
    • Resolution: Fixed
    • Icon: Major Major
    • core
    • Jenkins 1.411 / MacOS X / JDK 1.6.0_24
      Jenkins 1.412 / Master: Ubuntu 10.04, / Slave: Windows Server 2008 x64, JDK 1.6.0_20
      Jenkins 1.424.2 / Master: CentOS 5.5, / Slave: Windows Server 2008 R2 x64, JDK 1.6.0_21

      When launching a headless slave, a NoClassDefFoundError on org/apache/commons/codec/binary/Base64 is raised when specifying the -jnlpCredential option:

      $ java -jar slave.jar -jnlpUrl <url> -jnlpCredentials <user>:<password>
      Exception in thread "main" java.lang.NoClassDefFoundError: org/apache/commons/codec/binary/Base64
      at hudson.remoting.Launcher.parseJnlpArguments(Launcher.java:221)
      at hudson.remoting.Launcher.run(Launcher.java:192)
      at hudson.remoting.Launcher.main(Launcher.java:168)
      Caused by: java.lang.ClassNotFoundException: org.apache.commons.codec.binary.Base64
      at java.net.URLClassLoader$1.run(URLClassLoader.java:202)
      at java.security.AccessController.doPrivileged(Native Method)
      at java.net.URLClassLoader.findClass(URLClassLoader.java:190)
      at java.lang.ClassLoader.loadClass(ClassLoader.java:307)
      at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:301)
      at java.lang.ClassLoader.loadClass(ClassLoader.java:248)
      ... 3 more

          [JENKINS-9679] NoClassDefFoundError on Base64 when launching an headless slave with -jnlpCredential option

          Tiago Pais added a comment -

          Hi,

          I have this same problem on a Windows Server 2008 slave connecting to a Linux master.
          It's a x64 machine.

          Do anyone knows of a fast workaround? Like adding http://commons.apache.org/codec/ somewhere?

          Thanks,

          Tiago

          Tiago Pais added a comment - Hi, I have this same problem on a Windows Server 2008 slave connecting to a Linux master. It's a x64 machine. Do anyone knows of a fast workaround? Like adding http://commons.apache.org/codec/ somewhere? Thanks, Tiago

          Mariusz S added a comment -

          I have this error on W2008 with Tomcat 7 secured by SSL. Installing proper SSL cert in java keychain resolved this.

          Mariusz S added a comment - I have this error on W2008 with Tomcat 7 secured by SSL. Installing proper SSL cert in java keychain resolved this.

          Adding commons-codec-1.5.jar in the classpath worked for us:

          $ java -jar slave.jar -cp /path/to/commons-codec-1.5.jar -jnlpUrl <url> -jnlpCredentials <user>:<password>

          Olivier Mansion added a comment - Adding commons-codec-1.5.jar in the classpath worked for us: $ java -jar slave.jar -cp /path/to/commons-codec-1.5.jar -jnlpUrl <url> -jnlpCredentials <user>:<password>

          Tiago Pais added a comment - - edited

          I was using -noCertificateCheck so there was no issue with SSL certificates. Either way thanks for the suggestion.

          Meanwhile i was able to find a workaround:

          1. After installing Hudson Slave as a service I got to the local (on Slave) directory and found jenkins-slave.xml
          2. I edit the <arguments> entry to add the necessary jar to the invocation classpath:
            1. commons-codec-1.5.jar is the jar missing and you can grab it here (just unzip and it's there)
            2. Put commons-codec-1.5.jar in the local slave directory (inside a newly created lib directory)
            3. Change the <arguments> entry to add commons-codec-1.5.jar to the classpath like this -Xrs -jar "%BASE%\slave.jar" -jnlpUrl <url_to_jnlp> -classpath "%BASE%\lib\commons-codec-1.5.jar" -jnlpCredentials <user>:<password> -noCertificateCheck
          3. Start service in windows and monitor jenkins-slave.err.log

          Hope it helps,

          Tiago

          Olivier Mansion found it pretty much at the same time. Thanks anyway

          Tiago Pais added a comment - - edited I was using -noCertificateCheck so there was no issue with SSL certificates. Either way thanks for the suggestion. Meanwhile i was able to find a workaround: After installing Hudson Slave as a service I got to the local (on Slave) directory and found jenkins-slave.xml I edit the <arguments> entry to add the necessary jar to the invocation classpath : commons-codec-1.5.jar is the jar missing and you can grab it here (just unzip and it's there) Put commons-codec-1.5.jar in the local slave directory (inside a newly created lib directory) Change the <arguments> entry to add commons-codec-1.5.jar to the classpath like this -Xrs -jar "%BASE%\slave.jar" -jnlpUrl <url_to_jnlp> -classpath "%BASE%\lib\commons-codec-1.5.jar" -jnlpCredentials <user>:<password> -noCertificateCheck Start service in windows and monitor jenkins-slave.err.log Hope it helps, Tiago Olivier Mansion found it pretty much at the same time. Thanks anyway

          Would love to see this addressed or elevated in priority - this is a critical component of putting together a master/slave cluster, and has been known for just about a year now. I say this without being able to fix it myself of course but this would be a great help to people setting up multi configuration systems.

          Liam Staskawicz added a comment - Would love to see this addressed or elevated in priority - this is a critical component of putting together a master/slave cluster, and has been known for just about a year now. I say this without being able to fix it myself of course but this would be a great help to people setting up multi configuration systems.

          Harry G. added a comment -

          This is really somewhat clumsy and non intuitive, this foils the simple jnlp slave concept...
          Wouldn't it be easy to deliver commons-codec with the slave and set it in the cp by default?

          Harry G. added a comment - This is really somewhat clumsy and non intuitive, this foils the simple jnlp slave concept... Wouldn't it be easy to deliver commons-codec with the slave and set it in the cp by default?

          Still exists in 1.480.1, Workaround from Tiago Pais works.

          Rainer Weinhold added a comment - Still exists in 1.480.1, Workaround from Tiago Pais works.

          I wasted two hours trying to get JNLP (installed as service) to work before finding this bug. When is this going to be fixed? It's been a year! At least document it somewhere!

          Andrew Collette added a comment - I wasted two hours trying to get JNLP (installed as service) to work before finding this bug. When is this going to be fixed? It's been a year! At least document it somewhere!

          sogabe added a comment -

          sogabe added a comment - I've created pull request https://github.com/jenkinsci/remoting/pull/9 .

          Code changed in jenkins
          User: Kohsuke Kawaguchi
          Path:
          pom.xml
          src/main/java/hudson/remoting/Base64.java
          src/main/java/hudson/remoting/Engine.java
          src/main/java/hudson/remoting/Launcher.java
          src/test/java/hudson/remoting/BinarySafeStreamTest.java
          http://jenkins-ci.org/commit/remoting/ecf7f30df0f0e084eafa5c08f5569cbdca1dbaf5
          Log:
          [FIXED JENKINS-9679] Don't depend on commons-codec

          After all, we just need base64 encoder.

          SCM/JIRA link daemon added a comment - Code changed in jenkins User: Kohsuke Kawaguchi Path: pom.xml src/main/java/hudson/remoting/Base64.java src/main/java/hudson/remoting/Engine.java src/main/java/hudson/remoting/Launcher.java src/test/java/hudson/remoting/BinarySafeStreamTest.java http://jenkins-ci.org/commit/remoting/ecf7f30df0f0e084eafa5c08f5569cbdca1dbaf5 Log: [FIXED JENKINS-9679] Don't depend on commons-codec After all, we just need base64 encoder.

          Code changed in jenkins
          User: Kohsuke Kawaguchi
          Path:
          changelog.html
          pom.xml
          http://jenkins-ci.org/commit/jenkins/8a4bedd0df9b5d642945eb601ddb99bb75e87131
          Log:
          [FIXED JENKINS-9679] integrated remoting 2.21 that contains the fix.

          SCM/JIRA link daemon added a comment - Code changed in jenkins User: Kohsuke Kawaguchi Path: changelog.html pom.xml http://jenkins-ci.org/commit/jenkins/8a4bedd0df9b5d642945eb601ddb99bb75e87131 Log: [FIXED JENKINS-9679] integrated remoting 2.21 that contains the fix.

          Yury Zaytsev added a comment -

          Thank you, KK!~

          Yury Zaytsev added a comment - Thank you, KK!~

          dogfood added a comment -

          Integrated in jenkins_main_trunk #2186
          [FIXED JENKINS-9679] integrated remoting 2.21 that contains the fix. (Revision 8a4bedd0df9b5d642945eb601ddb99bb75e87131)

          Result = UNSTABLE
          kohsuke : 8a4bedd0df9b5d642945eb601ddb99bb75e87131
          Files :

          • changelog.html
          • pom.xml

          dogfood added a comment - Integrated in jenkins_main_trunk #2186 [FIXED JENKINS-9679] integrated remoting 2.21 that contains the fix. (Revision 8a4bedd0df9b5d642945eb601ddb99bb75e87131) Result = UNSTABLE kohsuke : 8a4bedd0df9b5d642945eb601ddb99bb75e87131 Files : changelog.html pom.xml

          Sergej Kleva added a comment -

          Sorry for asking ... but how can i integrate that fix into my Jenkins ver. 1.498 ?

          Thanks!

          Sergej Kleva added a comment - Sorry for asking ... but how can i integrate that fix into my Jenkins ver. 1.498 ? Thanks!

          sogabe added a comment -

          All you have to do is updating your Jenkins to 1.499.

          sogabe added a comment - All you have to do is updating your Jenkins to 1.499.

          Sergej Kleva added a comment -

          Thanks! Greatly appreciated!

          Sergej Kleva added a comment - Thanks! Greatly appreciated!

          Sergej Kleva added a comment -

          Hi!
          I've updated to 1.499 but error is still there:

          -Xrs -jar "%BASE%\slave.jar" -jnlpUrl http://aaa.bbb.ccc:8080/computer/slave01/slave-agent.jnlp -classpath "%BASE%\commons-codec-1.7.jar" -jnlpCredentials xxx:yyy -noCertificateCheck

          Error:

          Exception in thread "main" java.lang.NoClassDefFoundError: org/apache/commons/codec/binary/Base64
          at hudson.remoting.Launcher.parseJnlpArguments(Launcher.java:229)
          at hudson.remoting.Launcher.run(Launcher.java:200)
          at hudson.remoting.Launcher.main(Launcher.java:173)
          Caused by: java.lang.ClassNotFoundException: org.apache.commons.codec.binary.Base64
          at java.net.URLClassLoader$1.run(Unknown Source)
          at java.security.AccessController.doPrivileged(Native Method)
          at java.net.URLClassLoader.findClass(Unknown Source)
          at java.lang.ClassLoader.loadClass(Unknown Source)
          at sun.misc.Launcher$AppClassLoader.loadClass(Unknown Source)
          at java.lang.ClassLoader.loadClass(Unknown Source)
          ... 3 more

          Sergej Kleva added a comment - Hi! I've updated to 1.499 but error is still there: -Xrs -jar "%BASE%\slave.jar" -jnlpUrl http://aaa.bbb.ccc:8080/computer/slave01/slave-agent.jnlp -classpath "%BASE%\commons-codec-1.7.jar" -jnlpCredentials xxx:yyy -noCertificateCheck Error: Exception in thread "main" java.lang.NoClassDefFoundError: org/apache/commons/codec/binary/Base64 at hudson.remoting.Launcher.parseJnlpArguments(Launcher.java:229) at hudson.remoting.Launcher.run(Launcher.java:200) at hudson.remoting.Launcher.main(Launcher.java:173) Caused by: java.lang.ClassNotFoundException: org.apache.commons.codec.binary.Base64 at java.net.URLClassLoader$1.run(Unknown Source) at java.security.AccessController.doPrivileged(Native Method) at java.net.URLClassLoader.findClass(Unknown Source) at java.lang.ClassLoader.loadClass(Unknown Source) at sun.misc.Launcher$AppClassLoader.loadClass(Unknown Source) at java.lang.ClassLoader.loadClass(Unknown Source) ... 3 more

          The same with me in 1.499 - the issue was not solved.
          Failing to obtain <server>/slave-agent
          .jnlp
          java.io.IOException: Failed to load <server>/slave-agent.jnlp: 403 Forbidden
          at hudson.remoting.Launcher.parseJnlpArguments(Launcher.java:230)
          at hudson.remoting.Launcher.run(Launcher.java:192)
          at hudson.remoting.Launcher.main(Launcher.java:168)

          Alexander Artemov added a comment - The same with me in 1.499 - the issue was not solved. Failing to obtain <server>/slave-agent .jnlp java.io.IOException: Failed to load <server>/slave-agent.jnlp: 403 Forbidden at hudson.remoting.Launcher.parseJnlpArguments(Launcher.java:230) at hudson.remoting.Launcher.run(Launcher.java:192) at hudson.remoting.Launcher.main(Launcher.java:168)

          sogabe added a comment -

          @Sergej Did you update slave.jar?

          sogabe added a comment - @Sergej Did you update slave.jar?

          Sergej Kleva added a comment -

          If i put this way i get mentioned error above:
          -Xrs -jar "%BASE%\slave.jar" -jnlpUrl http://aaa.bbb.ccc:8080/computer/slave01/slave-agent.jnlp -jnlpCredentials xxx:yyy -noCertificateCheck

          If i put it this way i don't get errors and can successfully connect slaves:
          -Xrs -jar "%BASE%\slave.jar" -jnlpUrl http://aaa.bbb.ccc:8080/computer/slave01/slave-agent.jnlp -classpath "%BASE%\commons-codec-1.7.jar" -jnlpCredentials xxx:yyy -noCertificateCheck

          Sergej Kleva added a comment - If i put this way i get mentioned error above: -Xrs -jar "%BASE%\slave.jar" -jnlpUrl http://aaa.bbb.ccc:8080/computer/slave01/slave-agent.jnlp -jnlpCredentials xxx:yyy -noCertificateCheck If i put it this way i don't get errors and can successfully connect slaves: -Xrs -jar "%BASE%\slave.jar" -jnlpUrl http://aaa.bbb.ccc:8080/computer/slave01/slave-agent.jnlp -classpath "%BASE%\commons-codec-1.7.jar" -jnlpCredentials xxx:yyy -noCertificateCheck

          Jesse Glick added a comment -

          The authentication issue is unrelated: JENKINS-16273

          Jesse Glick added a comment - The authentication issue is unrelated: JENKINS-16273

          Jesse Glick added a comment -

          The issue was fixed in slave.jar 2.21, served from /jnlpJars/slave.jar, but the jenkins-slave.exe service wrapper continues to bundle 2.20.

          Jesse Glick added a comment - The issue was fixed in slave.jar 2.21, served from /jnlpJars/slave.jar , but the jenkins-slave.exe service wrapper continues to bundle 2.20.

          Jesse Glick added a comment -

          …or rather, launching the JNLP link seems to load from cache, and you have to manually delete e.g. C:\Documents and Settings\My Name\Local Settings\Application Data\Sun\Java\Deployment\cache and reload the JNLP to see the new 2.21 JAR. So it seems Jenkins is somehow not expiring old copies of the JAR properly, which ought to be fixed.

          Jesse Glick added a comment - …or rather, launching the JNLP link seems to load from cache, and you have to manually delete e.g. C:\Documents and Settings\My Name\Local Settings\Application Data\Sun\Java\Deployment\cache and reload the JNLP to see the new 2.21 JAR. So it seems Jenkins is somehow not expiring old copies of the JAR properly, which ought to be fixed.

          Jesse Glick added a comment -

          Reclosing; filed JENKINS-16490 to capture the cache issue, which is really independent.

          Jesse Glick added a comment - Reclosing; filed JENKINS-16490 to capture the cache issue, which is really independent.

          Code changed in jenkins
          User: Kohsuke Kawaguchi
          Path:
          changelog.html
          pom.xml
          http://jenkins-ci.org/commit/jenkins/7bc441d17c67d435c9b5e67dbca236abc124ff54
          Log:
          [FIXED JENKINS-9679] integrated remoting 2.21 that contains the fix.
          (cherry picked from commit 8a4bedd0df9b5d642945eb601ddb99bb75e87131)

          Conflicts:
          changelog.html
          pom.xml

          SCM/JIRA link daemon added a comment - Code changed in jenkins User: Kohsuke Kawaguchi Path: changelog.html pom.xml http://jenkins-ci.org/commit/jenkins/7bc441d17c67d435c9b5e67dbca236abc124ff54 Log: [FIXED JENKINS-9679] integrated remoting 2.21 that contains the fix. (cherry picked from commit 8a4bedd0df9b5d642945eb601ddb99bb75e87131) Conflicts: changelog.html pom.xml

          Would you please backport this LTS? I have to download commons-codec for every new node and adopt the classpath.
          Thanks in advance!

          Martin Scherer added a comment - Would you please backport this LTS? I have to download commons-codec for every new node and adopt the classpath. Thanks in advance!

          Jesse Glick added a comment -

          @marscher this was already backported to the stable branch (as 7bc441d); 1.480.3 has just not been released yet.

          Jesse Glick added a comment - @marscher this was already backported to the stable branch (as 7bc441d ); 1.480.3 has just not been released yet.

          Allan Chow added a comment -

          running on 1.481 and encountered this very issue?

          Allan Chow added a comment - running on 1.481 and encountered this very issue?

          Jesse Glick added a comment -

          @allan_chow this is not fixed in 1.481. You need to update to 1.480.3 or 1.499+.

          Jesse Glick added a comment - @allan_chow this is not fixed in 1.481. You need to update to 1.480.3 or 1.499+.

            jglick Jesse Glick
            mansion Olivier Mansion
            Votes:
            15 Vote for this issue
            Watchers:
            19 Start watching this issue

              Created:
              Updated:
              Resolved: