【问题标题】:NoSuchMethodError - Calling Class/Method from Class in Same PackageNoSuchMethodError - 从同一包中的类调用类/方法
【发布时间】:2014-09-02 13:03:49
【问题描述】:

我们正在将一个内部框架集成到我们的 weblogic 应用程序中,并且遇到了部署问题。

使用的技术

  • Weblogic 10.3.6 应用程序
  • 春季 3.0
  • Maven 2
  • Eclipse J2EE

问题

在 weblogic 应用程序启动时,我们在初始化其中一个 bean 时收到以下 NoSuchMethodError。调用 org.joda.time (2.0) jar 中的类时会出现此错误。

Caused By: java.lang.NoSuchMethodError: org.joda.time.DateTimeZone.convertLocalToUTC(JZ)J
      at org.joda.time.LocalDate.toDateTimeAtStartOfDay(LocalDate.java:715)
      at org.joda.time.LocalDate.toDateTimeAtStartOfDay(LocalDate.java:690)
      . . . excluded . . .

我们尝试过的事情

  • 在谷歌搜索“NoSuchMethodError spring”后,许多问题似乎与 Spring 版本不兼容。打印依赖树后,使用的唯一 Spring 版本是 3.0。

  • 谷歌搜索“NoSuchMethodError”通常会给出 JAR 地狱解决方案。

    • 同一依赖项的多个版本。在做了一些maven依赖管理之后,唯一使用的joda-time jar是2.0。此外,本地存储库已清除任何不必要的 jar。

    • .war / runtime 的 lib 目录中可能没有包含正确的 jar。查看 WEB_INF/lib 目录后,唯一的 joda-time jar 是 2.0 版,其中包含所有适当的类文件

一个神秘的事情是 DateTimeZone.convertLocalToUTC(JZ)J 自 1.0 以来一直是 org.joda.time 项目的一部分,所以即使我们有不兼容的版本,仍然应该找到该方法,特别是如果类和包都可以找到。

最后,项目中没有其他 DateTimeZone 类(在 eclipse 中按 ctrl+shift+T 搜索),所以如果没有加载 org.joda.DateTimeZone 类,我很困惑正在加载哪个类。

问题:

  • 谁能解释为什么找不到该方法?
  • 是否有更多地方可以检查现有或冲突的 jar?
  • 有没有办法通过 Eclipse 调试检查 LocalDate 类在运行时使用的 DateTimeZone 类?

【问题讨论】:

  • 如果您的 服务器库 中有 joda 时间库,是否有可能拥有旧版本?如果您的类加载策略优先选择服务器库,这可能会导致问题。
  • 您在 convertLocalToUTC 方法中传递了多少个参数?
  • @user2615897 已发布答案,如果有效,请查看
  • @Adi - 服务器库 (wlsserver_10.3/server/lib) 不包含任何 joda jars

标签: java eclipse spring maven jodatime


【解决方案1】:

这里有一些有趣的阅读:

prefer-web-inf-classes 元素

weblogic.xml Web 应用程序部署描述符包含一个 元素(的子元素 元素)。默认情况下,此元素设置为 错误的。将此元素设置为 True 会破坏类加载器 委托模型,以便来自 Web 应用程序的类定义 优先于更高级别的类定义加载 类加载器。这允许 Web 应用程序使用它自己的版本 第三方类,它也可能是 WebLogic Server 的一部分。看 “weblogic.xml 部署描述符元素。”

取自:http://docs.oracle.com/cd/E15051_01/wls/docs103/programming/classloading.html

其他故障排除提示:

您可以尝试:-verbose:class 并检查托管服务器的日志以检查类是否正确加载。

确认可能正在加载哪个侵入性 jar 的一种有效方法是在此应用的同一 Web 上下文(即 JVM 实例)中运行 whereis.jsp。

--whereis.jsp--

<%@ page import="java.security.*" %>
<%@ page import="java.net.URL" %>
<%
Class cls = org.joda.time.DateTimeZone.class;
ProtectionDomain pDomain = cls.getProtectionDomain();
CodeSource cSource = pDomain.getCodeSource();
URL loc = cSource.getLocation();
out.println(loc);
// it should print something like "c:/jars/MyJar.jar"
%>

您也可以在 $WEBLOGIC_HOME 文件夹上尝试 jarscan,看看是否可以找到包含此类的 jar:https://java.net/projects/jarscan/pages/Tutorial

【讨论】:

  • 谢谢! whereis.jsp 是调试的赢家!问题是 /modules 目录中的 joda-time jar:|在发布此问题之前,我们尝试通过主要方法获取位置,但这给出了预期的位置(m2 repo)。成功的一步是从正在运行的应用程序中获取位置。
  • 酷,很高兴你找到了根本原因:)
【解决方案2】:

NoSuchMethodError 几乎总是由于库版本冲突。在这种情况下,我猜这两个项目中有多个版本的 joda 库。

Weblogic 正在拉动org.joda jar。

尝试在您的 weblogic.xml 中添加此内容以排除 weblogic 正在拉取的 jar,而是使用您的应用程序 jar。

以下来自我的应用程序,您可以看看我们为我们的应用程序需要删除的所有内容。

<wls:container-descriptor>
        <wls:prefer-application-packages>
            <wls:package-name>antlr.*</wls:package-name>
            <wls:package-name>org.slf4j.*</wls:package-name>
            <wls:package-name>org.slf4j.helpers.*</wls:package-name>
            <wls:package-name>org.slf4j.impl.*</wls:package-name>
            <wls:package-name>org.slf4j.spi.*</wls:package-name>
            <wls:package-name>org.hibernate.*</wls:package-name>
            <wls:package-name>org.springframework.*</wls:package-name>
            <wls:package-name>javax.persistence.*</wls:package-name>
            <wls:package-name>org.apache.commons.*</wls:package-name>
            <wls:package-name>org.apache.xmlbeans.*</wls:package-name>
            <wls:package-name>javassist.*</wls:package-name>
            <wls:package-name>org.joda.*</wls:package-name>
            <wls:package-name>javax.xml.bind.*</wls:package-name>
            <wls:package-name>com.sun.xml.bind.*</wls:package-name>
            <wls:package-name>org.eclipse.persistence.*</wls:package-name>
        </wls:prefer-application-packages>

        <wls:show-archived-real-path-enabled>true</wls:show-archived-real-path-enabled>
    </wls:container-descriptor>

【讨论】:

  • 感谢您的回复!我尝试了该更改(以及 prefer-web-inf-classes 更改),但这些都不起作用。我们的应用程序相当大,是架构上的噩梦,所以有时这些解决方案不起作用。对于更简单的项目,我必须记住这一点。
猜你喜欢
  • 2016-10-22
  • 1970-01-01
  • 2017-10-17
  • 2013-02-17
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
相关资源
最近更新 更多