这里有一些有趣的阅读：

prefer-web-inf-classes元素

weblogic.xml Web应用程序部署描述符包含
元素（
元素的子元素）。默认情况下，此元素设置为
False。将此元素设置为True将颠覆类加载器
委托模型，以便Web应用程序
中的类定义优先于较高级别的
类加载器中的类定义。这允许Web应用程序使用自己的
版本的第三方类，这也可能是WebLogic Server的一部分。请参阅
weblogic.xml部署描述符元素。

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

其他疑难解答提示

您可以尝试：-verbose：类和检查您的受管服务器的日志，以检查是否正确加载该类。

确定哪个侵入式jar可能正在加载的有效方法是运行whereis。 jsp在这个应用程序的相同的webcontext（即JVM实例）中。

- whereis.jsp -

 <％@ page import =java.security。*％> 
<％@ page import =java.net.URL％> 
<％
类cls = org.joda.time.DateTimeZone.class; 
 ProtectionDomain pDomain = cls.getProtectionDomain（）; 
 CodeSource cSource = pDomain.getCodeSource（）; 
 URL loc = cSource.getLocation（）; 
 out.println（loc）; 
 //它应该打印像c：/jars/MyJar.jar
％> 
 

您还可以在$ WEBLOGIC_HOME文件夹上尝试jarscan，看看是否可以找到包含此课程： https://java.net/projects/jarscan/pages/Tutorial

We are integrating an internal framework into our weblogic application and we are running into deployment problems.

Technologies Used

• Weblogic 10.3.6 application
• Spring 3.0
• Maven 2
• Eclipse J2EE

The Problem

On startup of the weblogic application, we receive the following NoSuchMethodError while initializing one of the beans. This error is occuring when calling classes in the 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 . . .

Things We Have Tried

• After Googling "NoSuchMethodError spring", many of the problems seem to be incompatible Spring versions. After printing the dependency tree, the only Spring version in use is 3.0.

• Googling "NoSuchMethodError" usually gave JAR hell solutions.

  • Multiple versions of the same dependency. After doing some maven dependency management, the only joda-time jar in use is 2.0. Additionally, the local repository was purged of any unnecessary jars.

  • .war / runtime may not have the correct jars included in the lib directory. After looking into the WEB_INF/lib directory, the only joda-time jar is version 2.0, which contains all of the appropriate class files

One mysterious thing is that the DateTimeZone.convertLocalToUTC(JZ)J has been a part of the org.joda.time project since 1.0, so even if we have incompatible versions, the method should still be found, especially if the class and package are able to be found.

Finally there are no other DateTimeZone classes in the project (ctrl+shift+T search in eclipse) so I'm confused as to which class is being loaded if the org.joda.DateTimeZone class is not being loaded.

Questions:

• Can anyone explain why the method could not be found?
• Are there more places to check for existing or conflicting jars?
• Is there a way to check the DateTimeZone class that the LocalDate class is using during runtime via Eclipse debug?

Here's some interesting reading:

prefer-web-inf-classes Element

The weblogic.xml Web application deployment descriptor contains a element (a sub-element of the element). By default, this element is set to False. Setting this element to True subverts the classloader delegation model so that class definitions from the Web application are loaded in preference to class definitions in higher-level classloaders. This allows a Web application to use its own version of a third-party class, which might also be part of WebLogic Server. See "weblogic.xml Deployment Descriptor Elements."

taken from: http://docs.oracle.com/cd/E15051_01/wls/docs103/programming/classloading.html

Other troubleshooting tips:

You can try: -verbose:class and check your managed server's logs to check if the class is being loaded properly.

An efficient way to confirm which intrusive jar might be getting loaded is by running a whereis.jsp within the same webcontext (i.e., JVM instance) of this app.

--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"
%>

You can also try jarscan on your $WEBLOGIC_HOME folder to see if you can find the jar that contains this class: https://java.net/projects/jarscan/pages/Tutorial