Develop Reference

gwt-dev - Librairies with same package name

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.

PreparedStatement with list of parameters in a IN [duplicate]

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

OpenSAML Issue - NoClassDefFoundError for TrustMaterial (Java7, Maven)

We are seeing the following error when trying to complete a single-sign-on using OpenSAML. This was working, then seemed to stop when we upgraded to Java 7 (though that could very well be a red herring). We did install the JCE, so don't think it's related to that. Has anyone encountered this before?
java.lang.NoClassDefFoundError: Could not initialize class org.apache.commons.ssl.TrustMaterial
org.opensaml.xml.security.x509.X509Util.decodeCertificate(X509Util.java:319)
org.opensaml.xml.security.keyinfo.KeyInfoHelper.getCertificate(KeyInfoHelper.java:194)
org.opensaml.xml.security.keyinfo.KeyInfoHelper.getCertificates(KeyInfoHelper.java:169)
org.opensaml.xml.security.keyinfo.provider.InlineX509DataProvider.extractCertificates(InlineX509DataProvider.java:191)
org.opensaml.xml.security.keyinfo.provider.InlineX509DataProvider.process(InlineX509DataProvider.java:125)
org.opensaml.xml.security.keyinfo.BasicProviderKeyInfoCredentialResolver.processKeyInfoChild(BasicProviderKeyInfoCredentialResolver.java:299)
org.opensaml.xml.security.keyinfo.BasicProviderKeyInfoCredentialResolver.processKeyInfoChildren(BasicProviderKeyInfoCredentialResolver.java:255)
org.opensaml.xml.security.keyinfo.BasicProviderKeyInfoCredentialResolver.processKeyInfo(BasicProviderKeyInfoCredentialResolver.java:189)
org.opensaml.xml.security.keyinfo.BasicProviderKeyInfoCredentialResolver.resolveFromSource(BasicProviderKeyInfoCredentialResolver.java:148)
org.opensaml.xml.security.credential.AbstractCriteriaFilteringCredentialResolver.resolve(AbstractCriteriaFilteringCredentialResolver.java:57)
org.opensaml.xml.security.credential.AbstractCriteriaFilteringCredentialResolver.resolve(AbstractCriteriaFilteringCredentialResolver.java:37)
org.opensaml.security.MetadataCredentialResolver.retrieveFromMetadata(MetadataCredentialResolver.java:266)

Ensure not-yet-commons-ssl-0.3.9.jar is on the classpath of the JVM. That is the jar that contains the TrustMaterial class.

Java - UnresolvedAddressException due to lack of timezone info?

I'm looking for a few days for the solution to an UnresolvedAddressException I can't figure out!
It seems it's quite a challenging problem, since I couldn't even find other info on the net!
I'm working with OSGi framework on JamVM.
I get this exception when using Date.toString o SimpleDateFormat on a Calendar object. I can't understand why the bundle tries to connect after the getZoneStrings function. It seems it cannot find the locale but I'm not sure this is the problem.
I tried adding the file /etc/timezone (that was missing) but it didn't solve the problem.
Here's the complete stack trace of the exception:
adsdebian:/usr/local/bundle# org.osgi.framework.BundleException: Activator start error in bundle zApp_RoadPricing [24].
at org.apache.felix.framework.Felix.startBundle(Felix .java:1506)
at org.apache.felix.framework.BundleImpl.start(Bundle Impl.java:774)
at org.apache.felix.shell.impl.StartCommandImpl.execu te(StartCommandImpl.java:105)
at org.apache.felix.shell.impl.Activator$ShellService Impl.executeCommand(Activator.java:291)
at org.apache.felix.shell.remote.Shell.run(Shell.java :109)
at java.lang.Thread.run(Thread.java:743)
Caused by: java.nio.channels.UnresolvedAddressException
at gnu.java.nio.SocketChannelImpl.connect(SocketChann elImpl.java:160)
at gnu.java.net.PlainSocketImpl.connect(PlainSocketIm pl.java:281)
at java.net.Socket.connect(Socket.java:454)
at java.net.Socket.connect(Socket.java:414)
at gnu.java.net.protocol.http.HTTPConnection.getSocke t(HTTPConnection.java:719)
at gnu.java.net.protocol.http.HTTPConnection.getOutpu tStream(HTTPConnection.java:800)
at gnu.java.net.protocol.http.Request.dispatch(Reques t.java:291)
at gnu.java.net.protocol.http.HTTPURLConnection.conne ct(HTTPURLConnection.java:219)
at gnu.java.net.protocol.http.HTTPURLConnection.getHe aderField(HTTPURLConnection.java:582)
at java.net.URLConnection.getHeaderFieldInt(URLConnec tion.java:426)
at java.net.URLConnection.getContentLength(URLConnect ion.java:302)
at gnu.java.net.loader.RemoteURLLoader.getResource(Re moteURLLoader.java:79)
at java.net.URLClassLoader.findResources(URLClassLoad er.java:720)
at java.lang.ClassLoader.getResources(ClassLoader.jav a:640)
at gnu.classpath.ServiceFactory.lookupProviders(Servi ceFactory.java:286)
at java.util.ServiceLoader$1.hasNext(ServiceLoader.ja va:163)
at java.text.DateFormatSymbols.getZoneStrings(DateFor matSymbols.java:123)
at java.text.DateFormatSymbols.<init>(DateFormatSymbo ls.java:192)
at java.text.SimpleDateFormat.<init>(SimpleDateFormat .java:448)
at java.text.SimpleDateFormat.<init>(SimpleDateFormat .java:430)
at crf.opengate.app.roadpricing.RoadPricing.<init>(Ro adPricing.java:109)
at java.lang.reflect.Constructor.constructNative(Nati ve Method)
at java.lang.reflect.Constructor.newInstance(Construc tor.java:328)
at java.lang.Class.newInstance(Class.java:1154)
at org.apache.felix.framework.Felix.createBundleActiv ator(Felix.java:3341)
at org.apache.felix.framework.Felix.startBundle(Felix .java:1453)
...5 more
Is there anyone who could help me, please?
Thanks,
Andrea
Add to andre26's Reputation

Found this link which talks of a similar issue that got resolved by switching to Felix version 2.0.2. Maybe you could try that?

It's hard to be definitive without looking at the JamVM source code, but the stacktrace tells me that inside getZoneStrings there is an attempt to load a class or other file via the classloader (hence the call to ClassLoader and URLClassLoader three layers down the stack).
That attempt at classloading is not finding the address a URL that is in the classpath. That could be because you have a problem later on in your classpath and since it didn't find the file where you are putting your classes it went looking in the next place, which had an UnresolvedAddressException (by the way, that seems like an odd violation of the spec, the classloader should throw its checked exception. Here it seems that GNU classpath is letting a runtime exception leak out which should instead be converted into an exception indicating that the class cannot be found), or it could just be that that is what it does when it can't find a resource.
As for what class is not being found, it seems to be one of the ServiceProviders configured, perhaps in GNU Classpath:
at gnu.classpath.ServiceFactory.lookupProviders(Servi ceFactory.java:286)
The above is the core of the problem. It is looking up a provider, and attempted to get a resource from the classpath that likely doesn't exist.
It is impossible to say what exactly it is looking for without examining the source code. Fortunately you seem to be using all open source stuff, so it should be fairly easy to find.

Thanks JRL, the solution posted in the link you suggested me solved the problem!
I couldn't expect in such a bug of felix even because I thought I had already used Date and Calendar classes on the same platform and in the same conditions!
Just sum up of solution:
download newer version of felix (from at least 2.0.2) - from http://felix.apache.org/site/downloads.cgi get the .jar named Main (i.e. the bundle for the OSGi framework)
save it in the bin/ directory where your current felix.jar resides
rename felix.jar as felix.jar_old (after shutting down the OSGi FX if it's running!)
rename the newer version of felix (ex. org.apache.felix.main-2.0.3.jar) as felix.jar
restart the OSGi framework with your app
Hope this helps to someone else!
Bye,
Andrea
(Sorry for the second username...I register quite long time ago but I forgot about the google identification! :-) )

Hibernate in Servlet causesNoClassDefFoundError: org/slf4j/LoggerFactory

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.