java.lang.NoMethodError : org.apache.commons.codec.binary.Base64.encodeBase64URLSafeString答案

【问题标题】：java.lang.NoMethodError : org.apache.commons.codec.binary.Base64.encodeBase64URLSafeStringjava.lang.NoMethodError : org.apache.commons.codec.binary.Base64.encodeBase64URLSafeString
【发布时间】：2017-01-19 17:49:34
【问题描述】：

我的 Web 应用程序出现以下异常：

 java.util.concurrent.ExecutionException: java.lang.NoSuchMethodError:     org.apache.commons.codec.binary.Base64.encodeBase64URLSafeString([B)Ljava/lang/String;

commons-codec-1.5.jar 已添加到我的类路径中。我正在使用 Ant 构建它并手动添加了依赖项。通过对同一问题的其他讨论，我发现添加此库的源可以解决问题，但这对我不起作用。我还读到拥有另一个具有相同类的库可能会导致冲突，并且可能该类可能没有导致错误的此方法。但是，我已经仔细检查过没有同一个库的其他版本。是否有可能其他一些库中有相同的类？如果是，那么我该如何识别并解决问题？

【问题讨论】：

标签： java ant apache-commons apache-commons-codec

【解决方案1】：

正如您在问题中提到的那样，这是由于在编译时使用的 Base64 类的不同版本与在运行时使用的不同版本造成的。由于您使用的是 Ant（例如，而不是 Maven），因此应该更容易找到罪魁祸首，因为您不必担心传递依赖。

首先要做的是使用您的 IDE 打开类 Base64（在 IntelliJ 中为 ctrl+N），这将突出显示您的类路径中有多少不同版本的该库。就我而言，有 2 个。如果您有多个，那么您已经找到了罪魁祸首。

如果您的类路径中只有一个版本，那么该类唯一可以驻留的其他位置是 Tomcat 的 lib 目录中。您可能需要手动打开 jar 文件以查看是否包含相同的包 org.apache.commons.codec.binary...。

【讨论】：

非常感谢@StuPointerException 我能够在 csrfguard jar 中找到相同的包。但是 csrfguard jar 包含更新版本的 commons-codec jar 1.9 并且有方法 encodeBase64URLSafeString() 我得到 NoSuchMethodError。我的 jar 是 1.5 版的，它也有这个方法。这真的是问题的根源吗？
奇怪，查看 API 方法是在 1.4 中添加的，并且签名没有改变，所以我怀疑没有。
我找不到此问题的根本原因。但是我通过在我的项目中添加 commons-codec 的源代码解决了这个问题。因此，当 war 被打包时，Base64 的类文件将位于 WEB-INF\classes 中。类加载器将在 WEB-INF\lib 之前扫描此位置，从而避免由于 jar 引起的冲突。