We Keep Coding

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

This question already has answers here:
How do I fix a NoSuchMethodError?
(33 answers)
Closed 5 years ago.
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

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.

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

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

What are servletcontainer specific libraries?

In posts like https://stackoverflow.com/a/4076706/5467214 or https://stackoverflow.com/a/8743562/5467214 I keep reading about "servletcontainer specific libraries", that shouldn't be included manually in JavaEE projects, if I understood it correctly. Libraries like servlet-api.jar, jsp-api.jar, el-api.jar, j2ee.jar or javaee.jar are mentioned, but normally followed by an "etc.".
Is there a good explanation what "servletcontainer specific" means or perhaps an exhaustive list of which libraries are servletcontainer specific for Catalina, for example? Or for other servletcontainers? For example, jstl-1.1.2.jar gets explicitely loaded via the pom.xml in a project I am working on that runs on a Tomcat7. Is this "servletcontainer specific library"?

Can/should I depend on WebLogic's bundled modules

My target platform is a WebLogic 12c application server.
I have an ear-project, which on startup requires e.g. org.apache.commons.logging.LogFactory.
I know that this class - an related classes - can be found in <WL_HOME>/modules/com.bea.core.apache.commons.logging.api_1.1.1.jar, but it is not by default available on the classspath.
In such cases - am I supposed to somehow make the jar file in <WL_HOME>/modulesavailable on the classpath - or should I provide whatever jar file I find suitable - either bundled in the application, or placed in <WL_HOME>/user_projects/domains/<mydomain>/lib?
If I am to use the one in the <WL_HOME>/modules folder - how do I configure my domain to make it available?
To me it seems reasonable that the jar files in the modules folder should be considered provided dependencies, but so far I have been unable to find the right way to enable them as such - I have been browsing for an answer for hours:-)
UPDATE:
I know I can simply add them to the CLASSPATH variable in the server startup script - my question is more like - should I? Is there a better way - or should I completely forget about <WL_HOME>/modules?

That's a short-sighted approach.
you need to reboot the server to upgrade libraries
every app on the server must be okay with those libraries in their claspath
Weblogic has the concept of Shared JEE Libraries (example). In short, you add extra lines to MANIFEST.MF and configure the jar differently, then you can reference it in other apps using weblogic-application.xml or whatever.
The point is that you can upgrade the library without restarting the server (provided you gave it a version like 1.1 (there were bugs last time I named it 1.1.1 - it needed to be able to cast it to a floating-point number to seamlessly upgrade)).
If you just want to include some libraries but not share them outside the app, then just specify the correct <prefer-application-packages> or < prefer-web-inf-classes> element, depending on whether you have an EAR or a WAR.

WAS 6 steps to follow to support MQ 7 features

I have problem with EAR module deployed in WAS6.
To support the MQ 7 features in my App. I follow the below steps:
Put Class loader policy as PARENT_LAST.
Placed all MQ 7 related jars in the root of EAR.
EAR contains Web module. When I try to start the application, I got following exception:
javax.servlet.jsp.JspException: Can't get definitions factory from context.
at org.apache.struts.taglib.tiles.InsertTag.processDefinitionName(InsertTag.java:575)
at org.apache.struts.taglib.tiles.InsertTag.createTagHandler(InsertTag.java:474)
at org.apache.struts.taglib.tiles.InsertTag.doStartTag(InsertTag.java:436)
at com.ibm._jsp._home._jspx_meth_tiles_insert_0(_home.java:106)
at com.ibm._jsp._home._jspService(_home.java:81)
The War contains the following jars.
xstream-1.3.1.jar,xercesImpl.jar, xalan.jar,struts.jar, standard.jar,commons-validator.jar, commons-net-1.4.0.jar, commons-fileupload.jar, commons-digester.jar, commons-collections.jar, commons-beanutils.jar,resolver.jar,jstl.jar, jfreechart-1.0.2.jar, jcommon-1.0.5.jar, jaxen-full.jar, jakarta-oro.jar.
EAR contains the following Jars,
com.ibm.mqjms.jar, com.ibm.mq.jmqi.jar, com.ibm.mq.jar, com.ibm.mq.headers.jar, com.ibm.mq.commonservices.jar,log4j.jar,dhbcore.jar.
And I set the class-path attribute in my Manifest file of the WAR with log4j.jar
Please anyone suggest me how Websphere's classloading policy works for where I went wrong.
Karthik

Some time ago I did something similiar. I wanted to use a specific version of a library which was already used within the WebSphere Application Server. That is the reason why you have to put your libraries in the EAR file and set the application server to PARENT_LAST class loader order.
Correct me if I am wrong, but you also have to specify your custom MQ client libraries in Manifest of your WAR file. You only mentioned Log4J. It should look somehting like this:
Class-Path: com.ibm.mqjms.jar com.ibm.mq.jmqi.jar [...] log4j.jar
Anyway, you can always check what libraries are in the Classpath of you application if you log into the Integrated Solutions Console (aka Admin Console) and check the Troubleshooting section. There is a classloader viewer. Just click yourself through the tree and check which library path are mentioned and which you would expect.
Finally, as Dylan already mentioned in his comment: WebSphere Application Server version 6.1 runs out of support September 30, 2012. :)

Tomcat 4.1.24, slf4j 1.6.4, and activemq 5.5.1 Incompatibilities

I'm running into the following error when attempting to initialize a JMS connection between a servlet on Tomcat and a local ActiveMQ instace.
java.lang.NoSuchMethodError: org.slf4j.helpers.MessageFormatter.format(Ljava/lang/String;Ljava/lang/Object;)Lorg/slf4j/helpers/FormattingTuple;
at org.slf4j.impl.Log4jLoggerAdapter.warn(Log4jLoggerAdapter.java:420)
at org.apache.activemq.transport.tcp.TcpTransportFactory.createTransport(TcpTransportFactory.java:132)
at org.apache.activemq.transport.TransportFactory.doConnect(TransportFactory.java:141)
at org.apache.activemq.transport.TransportFactory.doConnect(TransportFactory.java:51)
at org.apache.activemq.transport.TransportFactory.connect(TransportFactory.java:80)
at org.apache.activemq.ActiveMQConnectionFactory.createTransport(ActiveMQConnectionFactory.java:243)
at org.apache.activemq.ActiveMQConnectionFactory.createActiveMQConnection(ActiveMQConnectionFactory.java:258)
at org.apache.activemq.ActiveMQConnectionFactory.createActiveMQConnection(ActiveMQConnectionFactory.java:230)
at org.apache.activemq.ActiveMQConnectionFactory.createTopicConnection(ActiveMQConnectionFactory.java:208) ...
I believe all my dependencies are in order. Other threads have suggested it's a problem with mismatched slf4j jar libraries. Here is my lib directory.
root#TestDebS:/usr/local/jakarta-tomcat-4.1.24/webapps/examples/WEB-INF# ls lib/
activemq-all-5.5.1.jar exolabcore-0.3.5.jar jndi_1.2.1.jar openjms-0.7.5.jar slf4j-api-1.6.4.jar
classes12.zip exolabcore-0.3.7.jar log4j-1.2.14.jar openjms-0.7.6.1.jar slf4j-log4j12-1.6.4.jar
comm.jar javax.comm.properties log4j-1.2.8.jar openjms-0.7.6.jar xercesImpl.jar
commons-logging-api.jar jms_1.0.2a.jar servlet.jar
Both [tomcat root]/common/lib and [tomcat root]/shared/lib have nothing noteworthy in them. Anyone have any ideas? Thanks in advance for any help you can give!

You have multiple versions of multiple libraries in your WEB-INF/lib; this is a bad idea as it can lead to mixing-and-matching of the different versions depending on which versions contain specific signatures.
Also, you must not deploy your own servlet.jar if that's the servlet API. The errors this causes are often non-obvious. May not solve this problem, but it will certainly stop others from occurring.