-1

Code used for decoding: Base64.decodeBase64("String");

Commons-codec jar version: 1.9

Exception: nested exception is java.lang.NoSuchMethodError: org.apache.commons.codec.binary.Base64.decodeBase64(Ljava/lang/String;)

Environment Details: OS: SunOS Version: 5.11 Java Version: 1.8.0_221 (Oracle corporation)

Same WAR working in below environment Environment Details: OS: AIX Version: 7.1 Java Version: 1.8.0_191 (IBM JDK)

Akilan R
  • 13
  • 5

1 Answers1

0

If you are getting a NoSuchMethodError, that means that you have a runtime version incompatibility problem. Some part of the codebase depends on1 a version of Base64 that has a method called decodeBase64 that takes a single String argument. But the version of the class that has been loaded doesn't have that method.

There is a clue in the javadoc for the method. It says that the method was added to the Base64 in version 1.4 of the API. So check the JAR files that are deployed to see if there is an older (pre 1.4) version of the Apache Commons Codec JAR on the runtime classpath.


1 - It could be a static dependency; i.e. a normal method call. It could also be a dynamic dependency; e.g. attempting to lookup the method using reflection.

Stephen C
  • 698,415
  • 94
  • 811
  • 1,216
  • I Checked that version also. 1.9 only there. same WAR working fine in AIX but not working in SunOS. Is there any configuration need to do? – Akilan R Jun 10 '20 at 13:13
  • Check that you are using the same version of Weblogic on both platforms. – Stephen C Jun 10 '20 at 13:17
  • weblogic version is same. Only difference is environment – Akilan R Jun 10 '20 at 13:18
  • It is possible that you have two different Apache Commons Codec JAR files in your WAR file. Check. If that doesn't help, change the JVM config to include "-verbose:class" and see where the `Base64` class is being loaded from. – Stephen C Jun 10 '20 at 13:22
  • Only you can find the problem, because only you have access to the environment. My guess is that there is a second `Base64` class in one of the jar, diverent environments can order jars in the classpath differently and java will load the class from the first jar it finds. suggestion by @StephenC is the best, use `-verbose:class` to find which jar `Base64` is loaded from. Is it the one you expect? – hidralisk Jun 10 '20 at 14:07