We Keep Coding

Class not found even when in Jar in the classpath

I am trying to deploy an application that is using Jackson, JUnit, and Commons-IO. I have the following Jars in my application's classpath:
commons-io-2.4.jar
jackson-databind-2.7.0.jar
jackson-annotations-2.7.0.jar
log4j-api-2.4.1.jar
wsdiscovery-0.2.jar
jackson-core-2.7.0.jar
log4j-core-2.4.1.jar
This application works within my development environment, and I have deployed all of the above Jars with the main application jar. I can run the application without problems, but every time I try to use it I get the following failure:
Exception in thread "main" java.lang.NoClassDefFoundError: com/fasterxml/jackson/databind/ObjectMapper
at com.oncam.hware.app.OnvifApp.formatOutput(OnvifApp.java:356)
at com.oncam.hware.app.OnvifApp.dispatchCommand(OnvifApp.java:271)
at com.oncam.hware.app.OnvifApp.loopSocket(OnvifApp.java:130)
at com.oncam.hware.app.OnvifApp.useSocket(OnvifApp.java:216)
at com.oncam.hware.app.OnvifApp.main(OnvifApp.java:473)
Caused by: java.lang.ClassNotFoundException: com.fasterxml.jackson.databind.ObjectMapper
at java.net.URLClassLoader.findClass(URLClassLoader.java:381)
at java.lang.ClassLoader.loadClass(ClassLoader.java:424)
at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:331)
at java.lang.ClassLoader.loadClass(ClassLoader.java:357)
... 5 more
The ObjectMapper class is in the jackson-databind-2.7.0.jar file. Furthermore, I have no problems accessing the classes in the other jar files (including the JUnit jars!). For some reason, it is as if the classloader is loading every Jar except jackson-databind-2.7.0.jar.
Does anyone know what is causing this and how I can fix it?
Someone please advise...

I figured out what was wrong.
It turns out that the environment I am using (Eclipse!) does not properly update the manifest file when you export your code to a JAR file. Without the proper manifest entries, the application cannot "find" the dependent jar files.
This is, in my opinion, a serious oversight on the part of the Eclipse folks -- especially when you have an application that depends on a lot of jar files. In order to make my application run, I had the following choices:
Create a script that runs the jvm and has a list of parameters pointing to every needed jar file, or:
2: Manually enter each required jar file into the Manifest file
To my knowledge, there is no way to automatically update the manifest file. This is a serious PITA (Pain In The A**)...
Anyway, sorry for bothering people about this problem. Hopefully, posting this answer will help others avoid similar problems...

using truezip in shadowJar built with gradle

i have a shadowJar compiled with gradle which uses truezip to get some files out of a zip-file.
i get this exception using it:
Exception in thread "main" java.util.ServiceConfigurationError: file (Unknown file system scheme! May be the class path doesn't contain the respective driver module or it isn't set up correctly?)
at de.schlichtherle.truezip.fs.FsAbstractCompositeDriver.newController(FsAbstractCompositeDriver.java:33)
at de.schlichtherle.truezip.fs.FsDefaultManager.getController0(FsDefaultManager.java:95)
at de.schlichtherle.truezip.fs.FsDefaultManager.getController(FsDefaultManager.java:78)
at de.schlichtherle.truezip.file.TBIO.getInputSocket(TBIO.java:280)
at de.schlichtherle.truezip.file.TFileInputStream.newInputStream(TFileInputStream.java:101)
at de.schlichtherle.truezip.file.TFileInputStream.<init>(TFileInputStream.java:95)
i set a archiveDetector like this:
final TArchiveDetector ad = new TArchiveDetector("foo", new ZipDriver(IOPoolLocator.SINGLETON));
TConfig.get().setArchiveDetector(ad);
the exception is thrown when i want to make an input-stream like this:
final TFileInputStream is = new TFileInputStream(thefile);
as far as i can tell the shadowJar contains all necessary classes, but maybe something is missing?
how would i know which class, which package is missing?
what else could cause this?
running it out of eclipse works...
thanks for any help.

That's a common issue when creating an uber-JAR: The individual entries at META-INF/services/* need to get appended. However, by default, many tools simply overwrite them when creating the uber-JAR. As a result, the ServiceLoader class cannot find all necessary plugins (e.g. for file system drivers), which is what this exception is complaining about.
So you need to fix the configuration of the tool which creates your uber-JAR. If you are using Maven with the maven-shade-plugin, then you can simply add the ServicesResourceTransformer - see https://maven.apache.org/plugins/maven-shade-plugin/examples/resource-transformers.html#ServicesResourceTransformer.
Another option is to not use an uber-JAR at all, which is the default when using Maven.
Eclipse can read Maven projects and establish its meta data from it, so maybe you want to consider converting your project to use Maven - if you haven't already.

I had the same problem. After some research i found the following solution:
In your build.gradle add the following:
shadowJar {
mergeServiceFiles()
}

ClassNotFoundException for org.osgi.framework.BundleActivator despite of Import-Package

I tried running a really simple OSGi "Hello World"-style example with an activator after a longer while again and got a ClassNotFoundException for org.osgi.framework.BundleActivator (see stack trace below).
The environment is basic Equinox (org.eclipse.osgi_3.7.2...). All bundles (besides mine) are ACTIVE. I have "org.osgi.framework" in my "Import-Package" declaration in the manifest, and I can see the class in the package dependencies in Eclipse.
Can someone give me a hint on what to try to troubleshoot this?
Kind regards,
André
Caused by: java.lang.ClassNotFoundException: org.osgi.framework.BundleActivator
at org.eclipse.osgi.internal.loader.BundleLoader.findClassInternal(BundleLoader.java:513)
at org.eclipse.osgi.internal.loader.BundleLoader.findClass(BundleLoader.java:429)
at org.eclipse.osgi.internal.loader.BundleLoader.findClass(BundleLoader.java:417)
at org.eclipse.osgi.internal.baseadaptor.DefaultClassLoader.loadClass(DefaultClassLoader.java:107)
at java.lang.ClassLoader.loadClass(ClassLoader.java:357)
... 30 more

Sorry for answering this myself, but others might have a similar confusing issue. What happened was that there was a third party library (in this case Jersey) requiring a newer version of OSGi that I had included. Hence that library could not find (the right version of) BundleActivator.

Make sure there is a line break after the last line of the
manifest

When executing JAR, get ExceptionInInitializerError: version.properties not found

I've been writing a small project in Eclipse which runs perfectly within the IDE. Then I've build a runnable .jar file through Eclipse (which should include every dependency library inside the jar itself).
I use 3 library in my project:
derby.jar
qtjambi-4.7.1.jar
qtjambi-win32-msvc2008-4.7.1.jar
Then I use this command (in windows):
java -jar prova.jar
And I get this:
Connected to database
Exception in thread "main" java.lang.reflect.InvocationTargetException
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
at java.lang.reflect.Method.invoke(Unknown Source)
at org.eclipse.jdt.internal.jarinjarloader.JarRsrcLoader.main(JarRsrcLoa
der.java:58)
Caused by: java.lang.ExceptionInInitializerError: version.properties not found!
at com.trolltech.qt.Utilities.<clinit>(Unknown Source)
at com.trolltech.qt.QtJambi_LibraryInitializer.<clinit>(Unknown Source)
at com.trolltech.qt.QtJambiObject.<clinit>(Unknown Source)
at WAAAGH.main(WAAAGH.java:52)
... 5 more
As you can see the derby.jar is working as expected ("Connected to database"), but there's an error with Qt-Jambi that I can't understand. Any idea?
EDIT: WAAAGH is the class containing the main method, line 52 consists in:
QApplication.initialize(args);

How is QtJambiObject getting loaded? Have you packeged it inside your prova.jar? The missing file version.properties should be part of the same jar at top level (not in any subdir). It seems you have not packaged it inside prova.jar at top level. See this for explanation of how it is loaded.
You might be better off specifying all jars and main class on command line:
java -classpath prova.jar;derby.jar;qtjambi-4.7.1.jar;qtjambi-win32-msvc2008-4.7.1.jar <your main class>
replace ; with : if you are running on *nix

FWIW the location of version.properties has recently been changed to be inside the package namespace of the bundles com/trolltech/qt/version.properties. The old location was a poor design choice and that has now been corrected. The issue is that if you have another JAR in your classpath that also has a toplevel file then the ClassLoader is entitled to think that the JAR with that file is authorative for the package and it does not need to search another JAR for the file. A package is a minimum deployable unit in Java, only specialist ClassLoaders (such as those use in OSGi) have features to work around this part of the Java design.
Usually your toplevel (application JAR) will be first in the list and I bet in that JAR you have one or more files like /log4j.properties /commons-logging.properties etc... it is because one or more file exists it then masks (hides) the file in the qtjambi-X.Y.Z.jar from being seen at runtime. Which is why the problem might not exist when you test a certain scenario but then appear when you try another (when you changed ClassPath in some way).
My commit to the project at http://qt.gitorious.org/qt-jambi/qtjambi-community/commit/f18ce5da3e30b43424bf94e49adf8c4cac0d9862 better explains in code the very recent change to make life better.
It should never have been the case that you have to copy the version.properties file from the QtJambi redistributable JARs into some other part of the Class Path (like the toplevel project prova.jar in your case) this is a bug that has been corrected for the next release. It is the long term intention to remove the need for the file completely and I am 80% there with that goal, as part of that work making multiple native JARs co-exist in the same Class Path will greatly simplify deployment and getting started guides; as well as making them play with OSGi and Eclipse nicely out-the-box.
However no releases have been made yet to include this change but I am very close (within 30 days of doing so for Qt 4.7.4).
Open Source plug alert: Please consider joining the mailing list at http://lists.qt.nokia.com/pipermail/qt-jambi-interest/ from http://lists.qt.nokia.com/mailman/listinfo for announcements.

Apache HttpClient throws a NoClassDefFoundError

I have: ubuntu-9.10-desktop-amd64 + NetBeans6.7.1
I just downloaded "Commons HttpClient 3.1 (legacy)" from http://hc.apache.org/downloads.cgi .
I created new application with IDE NetBeans.
I focused on Projects -> Libraries -> Add JAR/Folder and here added commons-httpclient-3.1.jar
By now, I can write "import org.apache.commons.httpclient.*;" This is OK.
But, if I try to add any statement included something like this:
public static void main(String[] args) {
HttpClient client = new HttpClient();
}
It is compiled well.
But when I run this project, I receive the following errors:
***Exception in thread "main" java.lang.NoClassDefFoundError: org/apache/commons/logging/LogFactory
at org.apache.commons.httpclient.HttpClient.<clinit>(HttpClient.java:66)
at SimplestAppl.Main.main(Main.java:22)
Caused by: java.lang.ClassNotFoundException: org.apache.commons.logging.LogFactory
at java.net.URLClassLoader$1.run(URLClassLoader.java:217)
at java.security.AccessController.doPrivileged(Native Method)
at java.net.URLClassLoader.findClass(URLClassLoader.java:205)
at java.lang.ClassLoader.loadClass(ClassLoader.java:319)
at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:294)
at java.lang.ClassLoader.loadClass(ClassLoader.java:264)
at java.lang.ClassLoader.loadClassInternal(ClassLoader.java:332)
... 2 more
Java Result: 1***
What is wrong?
I tried to download "HttpClient 4.0 (GA)". But the result was same.

What you are experiencing is just a missing dependency. Java developers are used to gather their dependencies themselves, esp. when it comes to logging frameworks.
Download commons-logging and add it to your classpath. Do as well with all other dependencies required by httpclient.

You need the dependencies. If you used maven, they would fetch themselves. Since you aren't, you've got to go download commons-logging (and perhaps others) and toss them in.

I'd like to update anyone coming here to the fact that all answers, and especially RocketSurgeon's, helped me solve my issue in the same sense. I had to download commons httpclient (legacy 3.1), logging and codec before my issues were resolved.
Also of note; using Eclipse I had to extract the .jar-files and import them into Buildpath using "add library". Did not work with only adding .zip-file.

If you dont want to use Maven, then
- build and launch, look at missing dependencies
- identify vendor, fetch the jar to resolve dependencies
- rinse/repeat until you have all dependencies satisfied
- done
anyway you will be never sure if all dependencies are 100% supplied. Its usually around 150% or 99%, but never in between