After upgrading some Glassfish/Grizzly dependencies (in order to be compatible with the latest version of Azure's SDK IOT device client), I started getting an error because com.google.common.EventBus no longer existed. Adding the dependency:
<dependency>
<groupId>com.google.guava</groupId>
<artifactId>guava</artifactId>
<version>15.0</version>
</dependency>
fixed that, and it was able to run locally in IntelliJ. However, when I deployed the .deb file that was compiled to a Raspberry Pi, it started producing the error:
java.lang.NoClassDefFoundError: javax/inject/Provider
at com.google.inject.internal.MoreTypes.canonicalizeForKey(MoreTypes.jav
a:81)
at com.google.inject.Key.(Key.java:119)
at com.google.inject.Key.get(Key.java:212)
at com.google.inject.spi.Elements$RecordingBinder.bind(Elements.java:262
)
at com.google.inject.internal.InjectorShell$RootModule.configure(InjectorShell.java:276)
at com.google.inject.spi.Elements$RecordingBinder.install(Elements.java:223)
at com.google.inject.spi.Elements.getElements(Elements.java:101)
at com.google.inject.internal.InjectorShell$Builder.build(InjectorShell.java:133)
at com.google.inject.internal.InternalInjectorCreator.build(InternalInjectorCreator.java:103)
at com.google.inject.Guice.createInjector(Guice.java:95)
at com.google.inject.Guice.createInjector(Guice.java:72)
at com.google.inject.Guice.createInjector(Guice.java:62)
at com.infusion.empm.Main.main(Main.java:32) Caused by: java.lang.ClassNotFoundException: javax.inject.Provider
at java.net.URLClassLoader$1.run(URLClassLoader.java:366)
I read in a number of places that adding the dependency
<dependency>
<groupId>javax.inject</groupId>
<artifactId>javax.inject</artifactId>
<version>1</version>
</dependency>
is supposed to fix that (I already had the guice & javax-servlet-api dependencies referenced here), but it had no effect. When I do so, the result is two javax.inject jars (the other one being generated would seem to explain why I didn't need to explicitly add version 1 to get it to run locally):
javax.inject-2.5.0-b42.jar
javax.inject-1.jar
Someone else here used exclusions when they had those two jars, but even when I change my hk2 dependency accordingly, both jars are still present. I've also heard that adding javax.ws.rs-api is supposed to help, but that was already there. The imports in the Java code refer directly to com.google.inject.Provider, so I don't think there's any need to call guicify to convert a JSR-330 provider to a Guice one. Replacing every "com.google.inject" import in the local code with "java.inject" results in the same exact behavior, so it must be a dependency referencing google's code, which is in turn failing to find javax.
It turned out the cause was a script on the Pi which hardcoded the jars in the classpath.
I am using commons-logging which should bridge to Log4J2 in an OSGi environment and so have added the dependencies, export-package and import-package in the pom.xml as below but the logger does not get set to Log4J2 logger. No errors are shown but when debugged I found it being set to JDK14Logger.
<dependency>
<groupId>org.apache.logging.log4j</groupId>
<artifactId>log4j-api</artifactId>
<version>2.8.2</version>
</dependency>
<dependency>
<groupId>org.apache.logging.log4j</groupId>
<artifactId>log4j-core</artifactId>
<version>2.8.2</version>
</dependency>
<dependency>
<groupId>org.apache.logging.log4j</groupId>
<artifactId>log4j-jcl</artifactId>
<version>2.8.2</version>
</dependency>
<dependency>
<groupId>commons-logging</groupId>
<artifactId>commons-logging</artifactId>
<version>2.8.2</version>
</dependency>
<Export-Package>
org.apache.logging.log4j.*,
org.apache.commons.logging.*
</Export-Package>
<Import-Package>
!org.apache.logging.log4j.*,
!org.apache.commons.logging.*,
*;resolution:=optional
</Import-Package>
[UPDATE]
From the log4j user mailing list I could figure out that due to the non-modular nature of ServiceLoader. I checked out a few usages of ServiceLoader in the OSGi environment to find implementations of interfaces but still couldn't get how this could be gotten to work.
I tried it using pax logging as well but the result is the same except for that the logger is now being set to JclLogger
As Christian said in the other answer, the best fit for logging in OSGI is the pax-logging bundle.
The Pax-logging is built over SLF4J and can be deployed with different possible implementations:
pax-logging-log4j2 (Log4J2)
pax-logging-logback (Logback)
Before we also used pax-logging-service which was using Log4J version 1 but it is not more recommended as the two other implementations works well.
I personally not tested Logback implementation in OSGI, but Log4j2 is working (with some limitations).
One of the good things with this solution is that you must not import any logging implementation on your bundles, the only things have to you do is:
declare slf4j-api as provided dependency (maven scope)
declare eventually the slf4j-simple as test scope in your maven
You don't need to tweak any of the maven-bundle-plugin options regarding logging of any of your bundles.
Here are the step how to do it in ServiceMix version 7.0.1; this release uses originally the pax-logging-services but the next step shows what need to be changed.
By installing the bundles in the startup.properties (immediately after boot time) you ensure that all libs are loaded in the beginning.
These two replace the older version of pax-logging-api and pax-logging-service replaced by pax-logging-log4j2:
mvn\:org.ops4j.pax.logging/pax-logging-api/1.11.13 = 8
mvn\:org.ops4j.pax.logging/pax-logging-log4j2/1.11.13 = 8
then in the file: org.ops4j.pax.logging.cfg you mentions just the line:
org.ops4j.pax.logging.log4j2.config.file=${karaf.etc}/log4j2.xml
and add your log4j2.xml file in the ${karaf.etc} folder (installation of servicemix/etc).
You have to copy the libs in the ${karaf.home}/system folder.
This is if you just need a standard log file.
Now come the limitations: if you need to generate your log as json document, I was only able to use the deprecated JSONLayout in the log4j2.xml.
For setting up JSONLayout you can follow my other answer.
In short:
Add the three Jackson dependencies in startup.properties:
mvn\:com.fasterxml.jackson.core/jackson-annotations/2.12.4 = 6
mvn\:com.fasterxml.jackson.core/jackson-core/2.12.4 = 6
mvn\:com.fasterxml.jackson.core/jackson-databind/2.12.4 = 6
and also the pax-logging-log4j2-extra (if you're using log4j2 implementation):
mvn\:org.ops4j.pax.logging/pax-logging-log4j2-extra/1.11.13 = 6
On my version I had to add the three following lines in overrides.properties:
mvn:com.fasterxml.jackson.core/jackson-core/2.12.4;range="[2,3)"
mvn:com.fasterxml.jackson.core/jackson-databind/2.12.4;range="[2,3)"
mvn:com.fasterxml.jackson.core/jackson-annotations/2.12.4;range="[2,3)"
I created a simple docker-compose with a servicemix 7.0.1 on github with the two ways of creating json logs (the new JsonTemplateLayout not working at the moment).
If the above is in your user bundle then this is not correct.
In your user bundle you should simply use the commons logging API and not change the settings of the maven bundle plugin.
It will then create Import-Package statements for the commons logging API but not for log4j which is what you want.
You then should install a suitable logging framework at runtime. I know that pax-logging can handle commons logging in a OSGi compatible way. Maybe plain log4j2 also works but I am not sure.
Please help,
For the past couple of days I have been trying to get Logback 1.1.3 to work with my Bukkit plugin. For reference my pom.xml includes these lines:
<dependency>
<groupId>ch.qos.logback</groupId>
<artifactId>logback-core</artifactId>
<version>1.1.3</version>
</dependency>
<dependency>
<groupId>ch.qos.logback</groupId>
<artifactId>logback-classic</artifactId>
<version>1.1.3</version>
</dependency>
And the following jars are listed under "Maven Dependencies":
logback-core-1.1.3.jar
logback-classic-1.1.3,jar
slf4j-api-1.7.7.jar (which appeared out of nowhere)
The stacktrace that the server console produces can be found here (line 29 of MoneyDrops.java is:
private static final Logger LOGGER = LoggerFactory.getLogger("MoneyDropsLogger");).
I have also searched through stackoverflow but all the answers suggest that I need to provide an implementation that use the SLF4J api (such as log4j), however, it is to my understanding that logback natively implements the api and that I do not need another jar file.
Any help would be greatly appreciated.
There's a dependency in the pom of logback-classic to slf4j which Maven will resolve. That's the reason of the "appeared out of nowhere".
If I read the documentation of JavaPluginLoader it says:
Represents a Java plugin loader, allowing plugins in the form of .jar
I'm not at all familiar with this library but I would interpret it as "This plugin will only load the specified jar" which would be the MoneyDrops jar.
Line 127 at https://github.com/Bukkit/Bukkit/blob/master/src/main/java/org/bukkit/plugin/java/JavaPluginLoader.java actually provides the bukkit classloader and a file as the classpath. I presume the file will be your jar.
So in order to make this work you'd need to somehow make your dependencies available to the classloader of bukkit. Maybe the minecraft server?
Another option is to unpack all the dependencies. The jars are compressed files anyway and repack them with your code. This way you can provide a single jar to the pluginloader. There's a maven plugin doing this for you but I forgot the name.
Thank you all for your help! I have concluded that I do not actually need logging in my plugin anyway (it is not that heavy) and have opted to remove it completely and rely on the Bukkit logger instead. Again, thank you all for your help.
I have a Maven Java project that uses Mashape Unirest for sending HTTP requests to other URLs. I am currently writing an integration test (using TestNG) that sends a normal HTTP request using Unirest. When I run the integration test through Maven (via the Failsafe plugin), the request is sent out successfully. However, when I try to run the integration test via Eclipse, I keep on getting the following error:
FAILED: getCurrentTimeTest
java.lang.NoSuchFieldError: INSTANCE
at org.apache.http.impl.io.DefaultHttpRequestWriterFactory.<init>(DefaultHttpRequestWriterFactory.java:52)
at org.apache.http.impl.io.DefaultHttpRequestWriterFactory.<init>(DefaultHttpRequestWriterFactory.java:56)
at org.apache.http.impl.io.DefaultHttpRequestWriterFactory.<clinit>(DefaultHttpRequestWriterFactory.java:46)
at org.apache.http.impl.conn.ManagedHttpClientConnectionFactory.<init>(ManagedHttpClientConnectionFactory.java:72)
at org.apache.http.impl.conn.ManagedHttpClientConnectionFactory.<init>(ManagedHttpClientConnectionFactory.java:84)
at org.apache.http.impl.conn.ManagedHttpClientConnectionFactory.<clinit>(ManagedHttpClientConnectionFactory.java:59)
at org.apache.http.impl.conn.PoolingHttpClientConnectionManager$InternalConnectionFactory.<init>(PoolingHttpClientConnectionManager.java:487)
at org.apache.http.impl.conn.PoolingHttpClientConnectionManager.<init>(PoolingHttpClientConnectionManager.java:147)
at org.apache.http.impl.conn.PoolingHttpClientConnectionManager.<init>(PoolingHttpClientConnectionManager.java:136)
at org.apache.http.impl.conn.PoolingHttpClientConnectionManager.<init>(PoolingHttpClientConnectionManager.java:112)
at org.apache.http.impl.client.HttpClientBuilder.build(HttpClientBuilder.java:726)
at com.mashape.unirest.http.options.Options.refresh(Options.java:41)
at com.mashape.unirest.http.options.Options.<clinit>(Options.java:27)
at com.mashape.unirest.http.HttpClientHelper.prepareRequest(HttpClientHelper.java:141)
at com.mashape.unirest.http.HttpClientHelper.requestAsync(HttpClientHelper.java:80)
at com.mashape.unirest.request.BaseRequest.asStringAsync(BaseRequest.java:56)
at ...
I am also able to reproduce this error using a basic Java application script.
I have made sure that the dependencies I am using in my pom.xml file are the latest and greatest, as seen below:
<dependency>
<groupId>com.mashape.unirest</groupId>
<artifactId>unirest-java</artifactId>
<version>1.3.5</version>
</dependency>
<dependency>
<groupId>org.apache.httpcomponents</groupId>
<artifactId>httpclient</artifactId>
<version>4.3.2</version>
</dependency>
<dependency>
<groupId>org.apache.httpcomponents</groupId>
<artifactId>httpasyncclient</artifactId>
<version>4.0</version>
</dependency>
<dependency>
<groupId>org.apache.httpcomponents</groupId>
<artifactId>httpmime</artifactId>
<version>4.3.2</version>
</dependency>
<dependency>
<groupId>org.json</groupId>
<artifactId>json</artifactId>
<version>20140107</version>
</dependency>
<dependency>
<groupId>org.apache.httpcomponents</groupId>
<artifactId>httpcore</artifactId>
<version>4.3.2</version>
</dependency>
I have also checked out the source code of BasicLineFormatter.java, both from the source file downloaded to Eclipse and from Apache's Httpcore Github repo. In the Github repo, notice how the INSTANCE field is defined for the 4.3.x branch and the trunk branch, but not in older branches like 4.2.x. However, I am indeed using version 4.3.2 in my project, so I should be using a JAR file for Httpcore that has the latest version of BasicLineFormatter. I know that, based on the Maven Dependencies JAR files that are in my project, that I am indeed using the latest versions of these Apache dependencies, not the older versions specified as downstream dependencies of my project.
I have checked other various SOF and blog posts about this issue, such as Mashape Unirest Java : java.lang.NoClassDefFoundError and this blog post too, but they all seem to be talking about solving the NoSuchFieldError problem for Android. However, I'm dealing with a standalone Java application, not an Android application.
I am at a loss in determining how to troubleshoot this issue. Anyone have any idea what I need to do?
UPDATE
Instead of showing my test case, I will reduce the illustration of a reproduction of this problem to just a simple one-liner Java application, because the problem exists with any Java application or test case run through Eclipse, not just one particular test:
System.out.println(Unirest.get("http://www.google.com").asStringAsync().get().getBody());
Normally, this should print the HTML of the Google home page, but I instead get the NoSuchFieldError stack trace.
FIXED!
The problem was that the AWS SDK (it's on my classpath because I'm developing for Elastic Beanstalk) had a conflicting JAR file. Using Oleg's solution (thanks BTW), I printed the following output in a unit test:
jar:file:/some/path/aws-java-sdk/1.7.1/third-party/httpcomponents-client-4.2.3/httpcore-4.2.jar!/org/apache/http/message/BasicLineFormatter.class
I'll have to rearrange my classpath so that AWS SDK is no longer conflicting.
The only plausible explanation to this problem is there is an older version of HttpCore on the classpath (unless you also want to consider a possibility of green men from Mars messing with your computer remotely from a flying saucer).
You can add this snippet to your code to find out what jar the class gets picked up from. This might help find out why that jar is on your classpath in the first place.
ClassLoader classLoader = MyClass.class.getClassLoader();
URL resource = classLoader.getResource("org/apache/http/message/BasicLineFormatter.class");
System.out.println(resource);
This basically tells me that in my case the jar resides in the local maven repository and likely to have been added to the classpath by Maven
jar:file:/home/oleg/.m2/repository/org/apache/httpcomponents/httpcore/4.3.1/httpcore-4.3.1.jar!/org/apache/http/message/BasicLineFormatter.class
As already mentioned by previous comments, It's mainly because of the conflicting versions of httpcore jar, the static field INSTANCE is been added to BasicLineFormatter class in versions > 4.3.1, Though you might have added the latest version of the httpcore jar in your dependencies, but its highly possible that other (lower) version of jar is getting picked up.
So, first to confirm that, wrong jar is getting picked up, Use the following line of code -
ClassLoader classLoader = <Your Class>.class.getClassLoader();
URL resource = classLoader.getResource("org/apache/http/message/BasicLineFormatter.class");
System.out.println(resource);
If this prints, the lower version of the jar, then it's confirmed that it's picking the lower version of the httpcore jar (May be from other dependencies of your project),
Solution -
Add following maven/gradle dependencies at the top of dependency list (Or above the other project dependency which caused the conflict) -
<dependency>
<groupId>com.mashape.unirest</groupId>
<artifactId>unirest-java</artifactId>
<version>1.4.5</version>
</dependency>
<dependency>
<groupId>org.apache.httpcomponents</groupId>
<artifactId>httpcore</artifactId>
<version>4.4.1</version>
</dependency>
<dependency>
<groupId>org.apache.httpcomponents</groupId>
<artifactId>httpclient</artifactId>
<version>4.4.1</version>
</dependency>
I faced the same exception using unirest:
java.lang.NoSuchFieldError: INSTANCE
at org.apache.http.impl.io.DefaultHttpRequestWriterFactory.<init>(DefaultHttpRequestWriterFactory.java:52)
at com.mashape.unirest.http.options.Options.refresh(Options.java:55)
at com.mashape.unirest.http.options.Options.<clinit>(Options.java:36)
And found it was due to DefaultConnectionKeepAliveStrategy.INSTANCE; and the conflicting jar was apache-httpcomponents-httpclient.jar in my classpath. Adding this post to help anyone who faces similar exception
I got this Exception: Caused by: java.lang.NoSuchFieldError: INSTANCE
Solution:
This happens if you have two different version classes in your classpath…. […], So I first find that class (one version of class), click that class, select build path, then I click remove from build path.
if you are using aws sdk this error occurs because of dependency mismatch.
To avoid this error do the following:
1.Put the dependecies in the required order aws sdk and the end preferably
2.Add shade plugin to the project
This solved my problem
you can refer to my answer in
HTTPClient Example - Exception in thread "main" java.lang.NoSuchFieldError: INSTANCE
my case is i have httpclient-4.4.1.jar, and httpcore-4.4.1.jar in my class path, but JVM loaded BasicLineFormatter from httpcore-4.0.jar
i am executing simple Dependency Injection program of spring & getting this exception.
I have already included common-logging1.1.1.jar and spring.jar file. Could you please help to out?
Exception in thread "main" java.lang.NoClassDefFoundError: org/apache/commons/logging/LogFactory
at org.springframework.context.support.AbstractApplicationContext.<init>(AbstractApplicationContext.java:119)
at org.springframework.context.support.AbstractXmlApplicationContext.<init>(AbstractXmlApplicationContext.java:55)
at org.springframework.context.support.ClassPathXmlApplicationContext.<init>(ClassPathXmlApplicationContext.java:77)
at org.springframework.context.support.ClassPathXmlApplicationContext.<init>(ClassPathXmlApplicationContext.java:65)
at org.springframework.context.support.ClassPathXmlApplicationContext.<init>(ClassPathXmlApplicationContext.java:56)
at com.client.StoryReader.main(StoryReader.java:15)
Caused by: java.lang.ClassNotFoundException: org.apache.commons.logging.LogFactory
at java.net.URLClassLoader$1.run(Unknown Source)
at java.security.AccessController.doPrivileged(Native Method)
at java.net.URLClassLoader.findClass(Unknown Source)
at java.lang.ClassLoader.loadClass(Unknown Source)
at sun.misc.Launcher$AppClassLoader.loadClass(Unknown Source)
at java.lang.ClassLoader.loadClass(Unknown Source)
at java.lang.ClassLoader.loadClassInternal(Unknown Source)
... 6 more
If you're using maven for managing dependencies, add the following lines in your pom.xml:
<dependency>
<groupId>commons-logging</groupId>
<artifactId>commons-logging</artifactId>
<version>1.1.1</version>
</dependency>
I have also faced the same issues, to fix, download the jar files from the below url
http://commons.apache.org/logging/download_logging.cgi
and copy to your lib folder, will resolve your issue.
You just download commons-logging-1.1.2.jar and then copy this file in to libs
finally, it works.
commons-logging-1.1.1.jar or jcl-over-slf4j-1.7.6.jar al
If you are using maven, use the below code.
<dependency>
<groupId>org.slf4j</groupId>
<artifactId>jcl-over-slf4j</artifactId>
<version>${slf4j.version}</version>
</dependency>
I had the same problem, and solved it by just adding the commons-logging.jar to the class path.
Setting the scope to compile did it for me
<dependency>
<groupId>commons-logging</groupId>
<artifactId>commons-logging</artifactId>
<version>1.2</version>
<scope>compile</scope>
</dependency>
Adding commons-logging.jar or commons-logging-1.1.jar will solve this...
I have already included common-logging1.1.1.jar and ...
Are you sure you spelled the name of the JAR file exactly right? I think it should probably be commons-logging-1.1.1.jar (note the extra - in the name). Also check if the directory name is correct.
NoClassDefFoundError always means that a class cannot be found, so most likely your class path is not correct.
Try doing a complete clean of the target/deployment directory for the app to get rid of any stale library jars. Make a fresh build and check that commons-logging.jar is actually being placed in the correct lib folder. It might not be included when you are building the library for the application.
Issue solved by adding commons-logging.jar
Imp files are ,
antlr-runtime-3.0.1
org.springframework.aop-3.1.0.M2
org.springframework.asm-3.1.0.M2
org.springframework.aspects-3.1.0.M2
org.springframework.beans-3.1.0.M2
org.springframework.context.support-3.1.0.M2
org.springframework.context-3.1.0.M2
org.springframework.core-3.1.0.M2
org.springframework.expression-3.1.0.M2
commons-logging-1.1.1
Two options (at least):
Add the commons-logging jar to your file by copying it into a local folder.
Note: linking the jar can lead to problems with the server and maybe the reason why it's added to the build path but not solving the server startup problem.
So don't point the jar to an external folder.
OR...
If you really don't want to add it locally because you're sharing the jar between projects, then...
If you're using a tc server instance, then you need to add the jar as an external jar to the server instance run configurations.
go to run as, run configurations..., {your tc server instance}, and then the Class Path tab.
Then add the commons-logging jar.
I got the same trouble than you.
Finally I checked the version of apache possessing the class.
I found that the version 1.0.4 has the class.
Try to use the version 1.0.4 instead of 1.1.X or 1.2.X
My dependencies :
<dependencies>
<dependency>
<groupId>org.jolokia</groupId>
<artifactId>jolokia-core</artifactId>
<version>1.3.5</version>
</dependency>
<dependency>
<groupId>org.jolokia</groupId>
<artifactId>jolokia-client-java</artifactId>
<version>1.3.5</version>
</dependency>
<dependency>
<groupId>commons-logging</groupId>
<artifactId>commons-logging</artifactId>
<version>1.0.4</version>
</dependency>
</dependencies>
My Java Code
J4pClient j4pClient = new J4pClient("http://localhost:8080/jolokia");
J4pReadRequest req = new J4pReadRequest("java.lang:type=Memory","HeapMemoryUsage");
req.setPath("used");
J4pReadResponse resp = j4pClient.execute(req);
System.out.println(resp.getValue());
My Result :
130489168
Double check also that your maven dependencies are well imported.
http://commons.apache.org/logging/download_logging.cgi
use this url to download jar files and include them in your class path, issue will be solved
The topic is very outdated. But it still can be met ourdays.
commons-logging, or also known as jcl is a deprecated library. The last version was exposed in 2014
You should avoid adding dependency on it directly in your projects. I assume the most of answers and the accepted one are not actual anylonger.
A preferrable way to use in your projects new alternatives, like slf4j or log4j2, which play the same role, as jcl. The reasons and motivation is another big topic, not for the scope of this issue.
If your application uses log4j2, and you meet the error, add dependency:
<dependency>
<groupId>org.apache.logging.log4j</groupId>
<artifactId>log4j-jcl</artifactId>
<version>2.y.z</version>
</dependency>
If you prefer slf4j, (already offered in previous comments/replies ) use:
<dependency>
<groupId>org.slf4j</groupId>
<artifactId>jcl-over-slf4j</artifactId>
<version>${slf4j.version}</version>
</dependency>
If you use Spring, most probably you have in the dependency tree:
<dependency>
<groupId>org.springframework</groupId>
<artifactId>spring-jcl</artifactId>
</dependency>
and it solves the issue as well.
In the examples I skipped certain versions by purpose, they get deprecated very quickly, see Offitial Maven repository.
In some cases you should not use version attribute at all, preferring using dependencies from BOM files. Spring is an example.
Just check whether the commons-logging.jar has been added to your libs and the classpath.. I had the same issue and that was because of this.
dhammikas-
I generally assign the classpath to a variable and then verify it. I've written a small ruby script which I include in a my startup scripts which validates the classpath before launching java. Validating the classpath before the JVM starts has saved me lots of time troubleshooting these types of problems.
Hey I was following the tutorial on tutorialpoint.com. Add after you complete Step 2 - Install Apache Common Logging API: You must import external jar libraries to the project from the files downloaded at this step. For me the file name was "commons-logging-1.1.1".
If you're running this on Android then note that apparently java.beans package is not complete on Android. To attempt to fix it on Android try the following:
Download android-java-air-bridge.jar (currently the download button is on the bottom of the page or direct link here)
Copy the downloaded jar to your [APPROOT]/app/libs directory (or link the jar in any other way)
Change the import *** statements to that of air-bridge. Eg import javadz.beanutils.BeanUtils instead of import org.apache.commons.beanutils.BeanUtils;
Clean and rebuild the project
source 1, source 2
I apologise as I realise this is not exactly answering the question, though this SO page comes up a lot when searching for android-generated NoClassDefFoundError: Failed resolution of: beanUtils errors.
I was getting the same error while the jar was present. No solution worked. What worked was deleting the jar from the file system (from .m2 directory) and then cleaning the maven project.
I have the same problem in eclipse IDE, my solution was:
Right click in My project > Properties
Click in Maven and write: jar in the Active Maven Project
Finally, Apply and Close
In my case I was testing a Tomcat app in eclipse and got this error. I solved it by checking the .classpath file and corrected this entry:
<classpathentry kind="con" path="org.eclipse.m2e.MAVEN2_CLASSPATH_CONTAINER">
<attributes>
<attribute name="maven.pomderived" value="true"/>
<attribute name="org.eclipse.jst.component.dependency" value="/WEB-INF/lib"/>
</attributes>
</classpathentry>
The attribute org.eclipse.jst.component.dependency had been missing.
Check whether the jars are imported properly. I imported them using build path. But it didn't recognise the jar in WAR/lib folder. Later, I copied the same jar to war/lib folder. It works fine now. You can refresh / clean your project.
Hello friends if your getting any not class found exception in hibernate code it is the problem of jar files.here mainly two problems
1.I mean to say your working old version of hibernate may be 3.2 bellow.So if u try above 3.6 it will works fine
2.first checkes database connection.if it database working properly their was a mistake in ur program or jar file.
please check these two prioblems if it also not working you tried to IDE . I am using netbeanside 6.9 version.here hibernate working fine.you dont get any error from class not founnd exception..
I hope this one helps more
try adding this dependency
org.apache.commons
commons-exec
1.3
If all else fails, as it had for me, try putting the commons-logging-x.y.z.jar in your Tomcat lib directory. It solved the problem! BTW, I am using Tomcat 6.
Solution is to Add common-logging.x.x jar file