NoSuchMethodError - Calling Class/Method from Class in Same Package

Question

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?

Answer 1

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

Answer 2

A NoSuchMethodError is almost always due to conflicting library versions. In this case I'm guessing there are multiple versions of joda libraries in the two projects.

Weblogic is pulling the org.joda jar.

Tryu adding this in your weblogic.xml to exclude the jar that weblogic is pulling, and instead use your appllication jar.

The below is from my application, you can have a look what all we have to removed for our application.

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