Clever Geek Handbook

NoSuchMethodError - calling a class / method from a class in one package

We are integrating backend framework into our weblogic application and we are facing deployment issues.

Technologies used

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

Problem

When starting the weblogic app, we get the following NoSuchMethodError while initializing one of the beans. This error occurs 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 Tried

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

  • Googling "NoSuchMethodError" usually gave hellish JAR solutions.

    • Several versions of the same dependency. After doing some maven dependency management, the only joda-jar version used is 2.0. In addition, the local repository has been cleared of unnecessary jars.

    • .war / runtime may not have the correct jars included in the lib directory. After examining the WEB_INF / lib directory, the only joda jar is version 2.0 which contains all the relevant class files

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

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

Questions:

  • Can anyone please explain why the method was not found?
  • Are there any more places to check existing or conflicting cans?
  • Is there a way to check the DateTimeZone class that the LocalDate class is using at runtime through Eclipse debugging?
+3


source to share


2 answers


Here are some interesting readings:

prefer-web-inf-classes Element

The weblogic.xml web application deployment descriptor contains an element (subelement element). By default, this element is set to False. Setting this element to True undermines the class loader to delegate the model so that class definitions from the web application are loaded instead of class definitions at a higher level class loaders. This allows the web application to use its own version of a third party class that can also be part of the WebLogic Server. See "Weblogic.xml Deployment Descriptor Items".

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

Other troubleshooting tips:

You can try: -verbose: class and check the managed server logs to see if the class is loaded correctly.



An efficient way of confirming which intrusive jar can be loaded is to run whereis.jsp on the same webcontext (i.e. JVM instance) of that application.

- 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 in the $ WEBLOGIC_HOME folder to see if you can find the jar that contains this class: https://java.net/projects/jarscan/pages/Tutorial

+2


source


A is NoSuchMethodError

almost always due to conflicting library versions . In this case, I am assuming there are multiple versions of joda libraries in the two projects.

Weblogic

pulls out a can org.joda

.

Try adding this to weblogic.xml

yours to exclude the jar the web logic is pulling out and use your jar appllication instead.



Below from my application you can see what is all that we have to remove 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>
0


source






More articles:


All Articles