Why java.lang.NoSuchMethodError occure very specific to environment or class loader?

Question

I am currently working on a project where we have the log4j-over-slf4j.jar file. In all of the environment, this jar was working. But all of a sudden I have a WebSphere application server. Our product works on tomcat server and all of the sudden our application was not able to create any logs whereas it was creating in another environment. If I try to remove that jar from the project then I am able to generate logs.

But I am not able to identify why should i do it only specific to this particular environment.

Or what should i do in order to identify the class loader information at server runtime to identify which class is loaded or which method is loaded?

My jdk version is: "1.7.0_71"

My application contains these libraries:

antlr-2.7.7.jar
aopalliance-1.0.jar
asm-1.5.3.jar
asm-attrs-1.5.3.jar
axiom-api-1.2.12.jar
axiom-impl-1.2.12.jar
axis2-1.6.2.jar
axis2-kernel-1.6.1.jar
axis2-transport-http-1.6.1.jar
axis2-transport-local-1.6.1.jar
c3p0-0.9.2.1.jar
cglib-2.1_3.jar
com.ibm.jbatch-tck-spi-1.0.jar
commons-codec-1.6.jar
commons-collections-3.1.jar
commons-fileupload-1.2.jar
commons-httpclient-3.1.jar
commons-logging-1.1.3.jar
dom4j-1.6.1.jar
ehcache-1.2.3.jar
geronimo-activation_1.1_spec-1.0.2.jar
geronimo-javamail_1.4_spec-1.6.jar
geronimo-jta_1.1_spec-1.1.jar
geronimo-stax-api_1.0_spec-1.0.1.jar
geronimo-ws-metadata_2.0_spec-1.1.2.jar
hibernate-3.2.4.ga.jar
hibernate-annotations-3.3.0.ga.jar
hibernate-commons-annotations-3.1.0.GA.jar
hibernate-core-3.3.0.CR2.jar
hibernate-ehcache-3.3.0.CR2.jar
hibernate-entitymanager-3.3.1.ga.jar
hibernate-jpa-2.0-api-1.0.0.Final.jar
hibernate-validator-3.1.0.CR2.jar
httpcore-4.0.jar
javaetmoi-spring4-vfs2-support-1.4.0.jar
javassist-3.18.1-GA.jar
javassist-3.3.GA.jar
javax.batch-api-1.0.jar
javax.servlet-api-3.0.1.jar
jaxen-1.1.1.jar
jboss-common-core-2.0.4.GA.jar
jboss-logging-3.3.0.Final.jar
jettison-1.2.jar
jsr311-api-1.0.jar
jta-1.1.jar
log4j-1.2.17.jar
log4j-api-2.0.jar
logkit-1.0.1.jar
mchange-commons-java-0.2.3.4.jar
neethi-3.0.1.jar
oracle-ojdbc6-11.2.0.3.0.jar
persistence-api-1.0.jar
poi-3.9.jar
slf4j-api-1.7.11.jar
slf4j-simple-1.6.4.jar
spring-aop-3.2.13.RELEASE.jar
spring-batch-core-3.0.1.RELEASE.jar
spring-batch-infrastructure-3.0.1.RELEASE.jar
spring-beans-3.2.13.RELEASE.jar
spring-context-3.2.13.RELEASE.jar
spring-core-3.2.13.RELEASE.jar
spring-expression-3.2.13.RELEASE.jar
spring-jdbc-3.2.13.RELEASE.jar
spring-orm-3.2.13.RELEASE.jar
spring-retry-1.0.3.RELEASE.jar
spring-tx-3.2.13.RELEASE.jar
spring-web-4.0.3.RELEASE.jar
stax-api-1.0.1.jar
woden-api-1.0M9.jar
woden-impl-commons-1.0M9.jar
woden-impl-dom-1.0M9.jar
wsdl4j-1.6.2.jar
wstx-asl-3.2.9.jar
xmlbeans-2.5.0.jar
xmlpull-1.1.3.1.jar
XmlSchema-1.4.7.jar
xpp3_min-1.1.4c.jar
xstream-1.4.7.jar

My tomcat lib directory contains:

annotations-api.jar
catalina-ant.jar
catalina-ha.jar
catalina.jar
catalina-storeconfig.jar
catalina-tribes.jar
ecj-4.5.jar
el-api.jar
jasper-el.jar
jasper.jar
jsp-api.jar
ojdbc6-11.2.0.3.jar
servlet-api.jar
sqljdbc4-11.1.0.7.0.jar
tomcat-api.jar
tomcat-coyote.jar
tomcat-dbcp.jar
tomcat-i18n-es.jar
tomcat-i18n-fr.jar
tomcat-i18n-ja.jar
tomcat-jdbc.jar
tomcat-jni.jar
tomcat-juli.jar
tomcat-util.jar
tomcat-util-scan.jar
tomcat-websocket.jar
websocket-api.jar

score 0 · Answer 1 · answered Dec 18 '17 at 07:55

Not sure about the precise environment, but I'm almost sure you're getting an unexpected version of some of the libraries classloaded. If the problem occurs after switching from Tomcat to WebSphere (or the other way around) chances are they either have different versions of something slf4-related (or one of them has a library that the other one is missing). Most of the time java's -verbose:class option should be usable for digging out what gets classloaded from where

score 0 · Answer 2 · answered Dec 18 '17 at 07:58

You get this type of error, when your code was compiled with a different version of code, than your environment is providing.

public class A{
 public void a(){
 }
}

//newer version of module
public class AVariant{
 public void a(String b){
 }
}

I'm not that familiar with WebSphere, but the issue here is that WebSphere uses an older/newer or version of logging framework, that is not compatible the version you are compiling your application. You need to resolve this dependency conflict.

This guide may help you with that: https://www.slf4j.org/legacy.html

Thanks for the answer, we know how NoSuchMethodError occurs, but my question is why do we have to remove that jar. — 5A9U, Dec 19 '17 at 07:26

score 0 · Accepted Answer · answered Dec 18 '17 at 08:25

NoSuchMethod error happens when your application tries to call a method on a previous version of a class which is not available on the newer version of the class. Bascically this can caused by a version conflict when upgrdading/downgrading or moving into a new environment.

See https://docs.oracle.com/javase/9/docs/api/java/lang/NoSuchMethodError.html

An indepth description is here.

Docker Image of Jersey Web Application

Checking application libs vs server provided libs wont be a use in here. What matters is what libs/classes are loaded by the JVM classloaders at runtime.

Analyse what are loaded class via java.class.path system property https://docs.oracle.com/javase/tutorial/essential/environment/sysprop.html

System.getProperty("java.class.path");

Then compare them with your tomcat version provided jars.

There has nothing changed in the classpath. It is still same. We are using bootstrap.jar & tomcat-juli.jar in the classpath of tomcat which is by default. — 5A9U, Dec 19 '17 at 07:24

Why java.lang.NoSuchMethodError occure very specific to environment or class loader?

3 Answers3