This is my first post on stackoverflow, please be indulgent.
Within my project, I use the library commons-digester-1.8.
Following a need, I now use the library gwt-dev-2.3.0.
When launching the application I get this error :
Exception caught while initializing context java.lang.NoSuchMethodError: org/apache/commons/digester/xmlrules/DigesterLoader.createDigester(Lorg/xml/sax/InputSource;)Lorg/apache/commons/digester/Digester;
at fr.cnasea.commons.webfwk.util.config.lecture.XMLDigesterReader.getConfig(XMLDigesterReader.java:157)
at fr.cnasea.commons.webfwk.util.config.CnaseaAppConfigurator.configure(CnaseaAppConfigurator.java:76)
at fr.cnasea.osiris.commons.gwt.server.Config.contextInitialized(Config.java:47)
It turns out that the two libraries have the same class in the same package with the same method:
Same class
Since the use of gwt-dev, it is the method of this library which is called.
I tried to use newer versions of gwt-dev but the environment makes it not possible
How can I fix it?
Thanks for your help :)
(From my answer to your same question on the github project)
The gwt-dev.jar should not be on your server classpath - it is only used to compile your application. The same is true for gwt-user.jar. Only gwt-servlet.jar (and possibly requestfactory-server.jar) should end up on your server classpath, the others are intended only to be present when compiling, either to do the work of compiling, or to provide the compiler the classes you need.
Related
What are the possible causes for ABstractMethodError?
Exception in thread "pool-1-thread-1" java.lang.AbstractMethodError:
org.apache.thrift.ProcessFunction.isOneway()Z
at org.apache.thrift.ProcessFunction.process(ProcessFunction.java:51)
at org.apache.thrift.TBaseProcessor.process(TBaseProcessor.java:39)
at com.gemfire.gemstone.thrift.hbase.ThreadPoolServer$ClientConnnection.run(Unknown Source)
at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
at java.lang.Thread.run(Thread.java:662)
It usually means that you are using an old version of an interface implementation which is missing a new interface method. For example java.sql.Connection interface got a new getSchema method in 1.7. If you have 1.6 JDBC driver and call Connection.getSchema you will get AbstractMethodError.
The simple answer is this: some code is trying to call a method which is declared abstract. Abstract methods have no body and cannot be executed. Since you have provided so little information I can't really elaborate more on how this can happen since the compiler usually catches this problem - as described here, this means the class must have changed at runtime.
From documnentation of AbstractMethodError
Thrown when an application tries to call an abstract method. Normally,
this error is caught by the compiler; this error can only occur at run
time if the definition of some class has incompatibly changed since
the currently executing method was last compiled.
A kind of special case of the above answer.
I had this error, because I was using a spring-boot-starter-parent (e.g. 2.1.0.RELEASE uses spring version: 5.1.2.RELEASE) but I also included a BOM, that also defined some spring dependencies, but in an older version (e.g. 5.0.9.RELEASE).
So one thing to do, is check your dependency tree (in Eclipse e.g. you can use the Dependency Hierarchy) if you are using the same versions.
So one solution could be that you upgrade the spring dependencies in your BOM, another one could be that you exclude them (but depending on the amount, this could be ugly).
If you download any project zip file, after unzipping them and importing into Android Studio, you are unable to run the project because this error happened.
I got out of the problem by deleting my android studio, then download and install the new version.
I truly hope it help.
If you you are getting this error on the implemented methods, make sure you have added your dependencies correctly as mentioned in this thread.
As Damian quoted :
Normally, this error is caught by the compiler; this error can only
occur at run time if [...]
I had the same error that was not caught by the compiler but at runtime. To solve it I only compiled again without giving the code any modification.
if you are getting this error on a minified build using Proguard then check if the class is a POJO class and if so then exclude it from the Proguard using the below rule:
-keep class your.application.package.pojo.** {*;}
I had the same error when I imported an eclipse project into intellij ide.. I tried to import it without .iml file then my problem was solved
I get this problem when I update my kotlin plugin to a new version .... the problem is that my pom file is using the older kotlin version .. I guess it might help someone if he is doing this mistake
I am getting various of these and others infrequently on android.. I have to clean everything change som configuration rebuild change configuration again to normal somehow just the build tools don't rebuild everything they should for whatever reason (Android gradle bug obviously).
I am trying to compile a java file, which uses package com.sun.xml.internal.messaging.saaj.soap.dynamic, using ANT-1.9.3 but I'm receiving error
package com.sun.xml.internal.messaging.saaj.soap.dynamic does not
exist
I tried compiling both JDK7 and JDK 8 and getting the same error.
I can see the package exist inside rt.jar of both JDK. I have set JAVA_HOME also properly.
Can someone help me to resolve this issue?
Unfortunately for you, this behaviour is probably intentional and your usage is deliberately unsupported. If your code used to compile under Java6 and now doesn't under Java7 or Java8 then you've basically fallen foul of
From one release to another, these classes may be removed, or they may be moved from one package to another
http://www.oracle.com/technetwork/java/faq-sun-packages-142232.html
See also http://bugs.java.com/bugdatabase/view_bug.do?bug_id=6778491 for a technical description of a possible cause of not being able to compile a class which references a 'com.sun.*' class but which throws the same compiler error you're seeing despite the fact that the referenced class exists in rt.jar. Also for the kind of response which Oracle give to bug reports relating to it;)
Unfortunately, using undocumented, unsupported APIs often has this kind of 'bite you in the posterior' kind of effect.
Please add the line, < compilerarg line="-XDignore.symbol.file" compiler="modern"/ > for < javac > tag in your build.xml. This should solve your problem. It solved for me.
For reference you can view the forum link
http://www.icesoft.org/JForum/posts/list/19871.page#sthash.srrN9Ijk.dpbs
I'm currently getting this error:
java.lang.NoSuchMethodError: org.json.JSONObject.keySet()Ljava/util/Set;
at ee.ut.cs.Parser.accessLint(Parser.java:39)
I have tried cleaning the project to no awail.
I suspect I have an error in the src/plugin/parse-htmlraw/build.xml while creating the jar file but I'm not certain. I understand that this error is because the function does not exist at runtime, but the object is created which means that the class is there, just not that function. I decompiled the .class file in created jar and it has the necessary functions.
Code is available at https://github.com/jaansusi/WCAGgrader
Q: What is wrong with the build that produces this error?
The problem is that even if I put the necessary class files in the jar I create, they are not linked correctly and the class that's called in the jar can't locate functions inside the other classes. The class object JSONObject is created but the functions inside the JSONObject class can't be found.
If you do not find the problematic version, there is a possibility you get it (especially if you are using Spring) from the following dependency -
<artifactId>android-json</artifactId>
<groupId>com.vaadin.external.google</groupId>
excluding it worked for me,
An easy way of analyzing dependencies is the maven-helper plugin in Intellij, see here
Check for the version you have used.
There might be a case where 2 different versions are being used which in turn causes this error.
To their own maven local repository com\Google\code\gson\gson, see if there are two or more version about json, will have to do is to delete the old, and remember to look at any other place in the project is introduced into the old version of the dependence, if any, change the old version of the dependence to the new version is perfectly solved this problem
Does anyone have any idea why something that used to work before all of a sudden started giving this error? please help
java.lang.NoSuchMethodError: org.apache.hadoop.mapred.Counters.findCounter(Ljava/lang/Enum;)Lorg/apache/hadoop/mapreduce/Counter;
at edu.umn.cs.spatialHadoop.operations.Sampler.sampleMapReduceWithRatio(Sampler.java:214)
at edu.umn.cs.spatialHadoop.operations.Sampler.sample(Sampler.java:543)
at edu.umn.cs.spatialHadoop.operations.Repartition.packInRectangles(Repartition.java:494)
at edu.umn.cs.spatialHadoop.operations.Repartition.packInRectangles(Repartition.java:463)
at edu.umn.cs.spatialHadoop.operations.Repartition.repartitionLocal(Repartition.java:590)
This has been working earlier but suddenly started giving this error. I am using hadoop version 1.2.1
Counter class is included in hadoop-mapreduce-client-core.jar. You must have downgraded it somehow.
If you are using a build tool (maven, gradle...), check your dependencies and make sure they haven't changed. In case of doubt, just apply the latest version.
Else, go to your hadoop-mapreduce-client-core.jar and either check if the method is inside or just get a newer version to replace it in your project.
from org/apache/hadoop/mapreduce/Counter I guess that the hadoop-mapreduce-client-core.jar is missing
This is because of latest compiled class and dependent jar available in the application are of different version. For example: Let Class A compiled with dependent jar X in place then later same Class A compiled in different environment withe dependent jar X1 which consist new method called Y in that. now the class will be compiled because new method Y is available in jar X1 when the same Class A is used in the environment with jar X in place then it leads to the NoSuchMethod Exception when trying to load the class in the class memory. Classloader does the verification of the dependent classes before loading the class in the class memory before invoking real exceution.
Everything were available all jar files and all. After an exhausting work thinking of whats wrong, i decided to reload everything afresh (i.e reload the hadoop files). Thanks to you guys for helping :)
I have a Java (6) application which uses Hibernate (V3.3.2) to read data from HSQLDB, which i build and debug/run with Eclipse (V3.5.1), and it works fine.
I then created a GWT (V1.7) Servlet web app, copied my hibernate classes into it, and added the same User Libraries dependencies. However when i run the servlet and try to access a URL which invokes my code i get this:
java.lang.NoClassDefFoundError: org/slf4j/LoggerFactory
at org.hibernate.cfg.Configuration.<clinit>(Configuration.java:152)
at xxx.daoimpl.DAOSession.initialise(DAOSession.java:40)
where DAOSession.java:40 is :
AnnotationConfiguration config = new AnnotationConfiguration ();
Googling for this error suggests i am missing slf4j-api.jar from the classpath, however if i look at the command line for the Debug properties i can see this jar there:
C:\java\jsedk_6\jre\bin\javaw.exe
-agentlib:jdwp=transport=dt_socket,suspend=y,address=localhost:54541
-Xmx512m -Dfile.encoding=Cp1252
-classpath
D:\dev\workspace\xxx\src;
D:\dev\workspace\xxx\resources;
D:\dev\workspace\xxx\war\WEB-INF\classes;
C:\java\eclipse\plugins\com.google.gwt.eclipse.sdkbundle.win32_1.7.1.v200909221731\gwt-windows-1.7.1\gwt-user.jar;
C:\java\eclipse\plugins\com.google.gwt.eclipse.sdkbundle.win32_1.7.1.v200909221731\gwt-windows-1.7.1\gwt-dev-windows.jar;
C:\java\hibernate-annotations-3.4.0.GA\hibernate-annotations.jar;
C:\java\hibernate-annotations-3.4.0.GA\lib\ejb3-persistence.jar;
C:\java\hibernate-annotations-3.4.0.GA\lib\hibernate-commons-annotations.jar;
C:\java\hibernate-distribution-3.3.2.GA\hibernate3.jar;
C:\java\hibernate-distribution-3.3.2.GA\lib\required\antlr-2.7.6.jar;
C:\java\hibernate-distribution-3.3.2.GA\lib\required\commons-collections-3.1.jar;
C:\java\hibernate-distribution-3.3.2.GA\lib\required\dom4j-1.6.1.jar;
C:\java\hibernate-distribution-3.3.2.GA\lib\required\javassist-3.9.0.GA.jar;
C:\java\hibernate-distribution-3.3.2.GA\lib\required\jta-1.1.jar;
C:\java\hibernate-validator-4.0.1.GA\hibernate-validator-4.0.1.GA.jar;
C:\java\hibernate-validator-4.0.1.GA\lib\validation-api-1.0.0.GA.jar;
C:\java\hibernate-validator-4.0.1.GA\lib\log4j-1.2.14.jar;
C:\java\hsqldb\lib\hsqldb.jar;
C:\java\restlet-jse-2.0m5\lib\org.restlet.jar;
C:\java\restlet-jee-2.0m5\lib\org.restlet.ext.servlet.jar;
C:\java\restlet-jse-2.0m5\lib\org.restlet.ext.xml.jar;
C:\java\slf4j-1.5.8\slf4j-api-1.5.8.jar;
C:\java\slf4j-1.5.8\slf4j-log4j12-1.5.8.jar
com.google.gwt.dev.HostedMode
...
If i open the jar i can see the LoggerFactory class in there.
Any idea why it isn't being found by the class loader?
Edit 1: If try to access org.slf4j.LoggerFactory from my code, Eclipse compiles it ok, but i get the same error at runtime.
Edit 2: If i add a Test class with a main which calls the same code and run it, it works. So this classpath problem seems specific to the Servlet.
thanks,
jon
It seems that copying the two slf4j jars to the war/WEB-INF/lib sub-project/dir fixed the problem. I'm not really sure why i should need to do this for these two jars and not for all the other Hibernate, Restlet etc jars that the project also uses, though i suppose for consistency i will do that anyway - i guess it will make deployment easier as well.
If someone can provide some sort of explanation as to why this worked and why exactly i need to do it i will select it as the "correct" answer, otherwise i'll select this one.
Can you please reconfirm that you have at least two slf4j.jar files in the classpath, the slf4j-api.jar and exactly one implementation, such as slf4j-jdk14.jar?
You must not have multiple sflj4-implementations in the classpath.
You have a runtime dependency issue so everything compiles fine but the dependency is in your jars. You need to visit the Hibernate site and look at the compatibility matrix and make sure you are matched up correctly then check the dependencies for annotations and core. You log4J jars look fine so it's definitely some quirk.
If it works in Eclipse then logically it's definitely some diff between the 2 runtimes (eclipse and non-eclipse), if the matrix checks out fine then see if you can factor out the commonalities in the 2 then work out the differences -- your answer should be in there.
I had a similar issue except I was using Tomcat and the NoClassDefFound error was on the juli logger. I fixed it by removing the Tomcat dependencies from my classpath when running in hosted mode because hosted mode embeds a Tomcat server that was conflicting. So I would see what happens if you remove some or all of the restlet jars from your classpath to see if they conflict.