I'm getting this error trying to access a value on cache from a Web Service, but when I called the method directly on a test class it works fine.
some one got this error?
Pastebin: http://pastebin.com/8z7bsDcc
I've try with it withour results: http://code.google.com/p/spymemcached/issues/detail?id=155&colspec=stars%20id%20Milestone%20Priority%20Status%20Summary
Thanks.
I just answered a similar question over here:
java.lang.NoClassDefFoundError from every class every day
It was related to the pom.xml and how resources were included.
Make sure you all required jars are available in webservice classpath.
You will get ClassNotFoundException if required class is not available in classpath.
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'm started working on an already existing project. In this project there is some JSON-parsing happening with the following exception being thrown by several methods:
JSONException.class
While I was unit-testing these parsers I couldn't import the right org.json.JSONException library.
The maven library used in the codebase was (package org.json.JSONException):
org.json:json:20160810
And the one that was importing in my tests was (package org.json.JSONException):
com.vaadin.external.google:android-json:0.0.20131108.vaadin1
I think the problem lies in both libraries share the same package names. When the test is execute the JSONException is thrown but the test still fails because its probably the other library. Anybody knows why this problem is happening and how to solve it?
Thanks in advance!
I believe you need to updated your pom.xml file and in the dependency section you can exclude a 3rd party dependency from a declared dependency. I guess in your case there is a dependency to json and vaadin, you'll find vaadin is also pulling the different version of json.
You can try removing one of them. As suggested here:
https://github.com/spring-cloud/spring-cloud-deployer-kubernetes/issues/142
This is my first time deploying to AWS Lambda and am getting a little stuck.
I have a large maven project called Helpers which has many submodules, many of them dependent on each other. In there I have one Helper called Alerts. I have a parent directory and everything builds and compiles successfully. So, that's good.
In Alerts there's a class called PaymentAlerts which has the line
import com.mywebsite.messages.Doers
where messages.Doers is found in the dependencies.
But, when I do a mvn package on the whole project and I find alerts-1.0.jar and upload it to AWS Lambda and I set my handler as com.mywebsite.alerts.PaymentAlerts::doAlert I get the following error:
{
com.mywebsite.alerts.PaymentAlerts: com/mywebsite/messaging/Doers",
"errorType": "java.lang.NoClassDefFoundError"
"errorMessage": "Error loading class
}
How do I reconfigure this so that it finds all the necessary files?
Any and all help is appreciated!
AWS Lambda can't find dependent library
Except mvn, you can do with simple library dependency by putting all jars in one, Where your MANIFEST file contains like Class-Path: libs/xyz.jar libs/abc.jar ...
Hope this process can resolve your "errorType": "java.lang.NoClassDefFoundError"
From here I was able to find out about maven-shade-plugin which jarred everything together nicely and solved the problem.
I'm trying to run a jersey client and facing this issue.
This problem gets out when i try to run the class on command prompt. While if i run it on intellij it works fine. Can anybody help me with that? Ps: i'm a beginner in java
#Anja.M we need more details in order to be able to help you. The most important thing when it comes to a java application is to create the class path correctly. I believe this is stated above. You need describe all this dependensies into the java command when you are starting the application. Jersey depends on libraries as well the class that is throwing your exception is contained within javax.ws.rs-api-2.0.1.jar. This file contains the missing javax/ws/rs/core/Response This file you need to include in the class path the following way:
java -classpath classpath1;classpath2...
Let me summarize. You have two type of dependencies one type is inside the /api folder when you download the jersey bundle. The second one is located under -lib
You need to make sure that /api content and the lib is in your class path. Maybe not all jar files are needed for the client side , but you can find out later. As a start include them all.
I have a Spring framework based Java web application, which has been built in SpringSource Tool Suite ("STS"), and a local copy of Apache Tomcat. We also have a internal production server, again running Tomcat.
When I run the application on my development machine, and carry out a specific action in the web application, everything works correctly. However, when I deploy the web application to Tomcat on the server (via a war file produced by maven), and repeat those aforementioned specific actions, I'm presented with some unexpected behaviour. When I checked the server tomcat log file, I found this...
2011-11-16 19:36:45,090 [http-8280-Processor1] ERROR [attachments] invoke - Servlet.service() for servlet attachments threw exception java.lang.NoSuchMethodError: net.wmfs.coalesce.aa.dao.MediaDao.updateAlfrescoNodeRef(Ljava/lang/Long;Ljava/lang/String;)V
at net.wmfs.coalesce.aa.service.impl.MediaServiceImpl.doFileUpload(MediaServiceImpl.java:102)
at net.wmfs.coalesce.aa.servlet.MediaServlet.doFileUpload(MediaServlet.java:83)
at net.wmfs.coalesce.aa.servlet.MediaServlet.doPost(MediaServlet.java:55)
Now, the updateAlfrescoNodeRef method definitly exists in the MediaDao class - otherwise my code would not compile in STS...
package net.wmfs.coalesce.aa.dao;
public class MediaDao extends JdbcDaoSupport {
public void updateAlfrescoNodeRef(final Long recordId, final String nodeRef) {
// java code
}
}
As you can see, the method signature is correct.
I suspected that there may have been a problem when maven produced the war file, so I extracted the war files contents. In the WEB-INF/lib folder, I found the jar file which holds the MediaDao class, and extracted its contents. I then did a...
cat ./MediaDao.class
Now, as class files are binary files, I mostly saw gobledegook. However, I was able to clearly make out references to the updateAlfrescoNodeRef method, as well as the contents of a String in that method. So, this means that the method is definitely there.
The bean configuration in the Spring framework XML files is definitely correct, or the code would not run when I execute it on my development machine.
Googling suggested a library conflict on the server, but all the referenced classes - MediaServlet, MediaServiceImpl, MediaDao - are in the main project (the one with the WEB-INF folder in it). While its conceivable there may be multiple copies of the dependencies on the server, there is definitely only one copy of the main project jar.
Does anyone have any ideas why this is happening?
The problem has now been resolved. Thank you everyone for your assistance.
It turns out that the main project had a dependency which had another MediaDao class, in exactly the same package path. Someone had basically copied the class into that dependency (as a library resource so that lots of projects could use it without specifying the main project as a dependency). However, that someone had not removed the class in the main project.
So, when I modified the class in the main project (I added the updateAlfrescoNodeRef method), and ran the application in STS on my machine, Tomcat used the version of the class in the main project, and not in the library because the library project was closed. When the application was deployed to the server however, it looks like the version of the class in the library was used instead (which, of course, didn't have the updateAlfrescoNodeRef method in it).
Expert tip if you ever find yourself in a similar situation: In STS, press CTRL+SHIFT+T to open the "Open Type" dialog, and enter the name of the problematic class to see a list of projects that have a class with that name.
If the error occured in android studio, it also can be a bug of the Instant Run. In that case: File -> Invalidate Caches/Restart. It solved my problem
If you are using Tomcat 6+, look in ~tomcat/lib for conflicting classes and jars.
In Tomcat 5, look in ~tomcat/common/classes, ~tomcat/common/lib, ~tomcat/shared/classes and ~tomcat/shared/lib.