Menu
We're currently investigating the use of OneJar in our application (for a number reasons), but our application makes use of a number of custom URLClassloaders to load application extensions.
When bundled as a "OneJar" Jar, we get ClassNotFound exceptions. The classes in question reside in the bundled Jar and we are simply relying on the classloader mechanism to resolve the parent/child relationship.
That is. We have a common interface which is stored in the bundled Jar (which should be the within the parent's classloader context). The extension implements this interface (allowing us to call into the extension) and relies on the ability of the child classloader to use the parent classloader's resource finding capabilities.
Has any one had any experience with this or shed any light on how we might go about resolving it.
I'd be interested in other similar mechanisms (for bundling our library Jar's into a single Jar resource, that doesn't require use to unjar everything and Jar into a single file)
625
In this example we shall show you Java Dynamic Class Loading, Dynamic Java Class loading is an important mechanism which provides the Java platform with the ability to install software components at run-time where you can load your classes in a lazy loading manner which means that classes are loaded on demand and at the last moment possible.
Class loaders in Java are organized into a hierarchy. When you create a new standard Java ClassLoader you must provide it with a parent ClassLoader. If a ClassLoader is asked to load a class, it will ask its parent class loader to load it. If the parent class loader can't find the class, the child class loader then tries to load it itself.
When a class is loaded, all classes it references are loaded too. This class loading pattern happens recursively, until all classes needed are loaded. This may not be all classes in the application. Unreferenced classes are not loaded until the time they are referenced. Class loaders in Java are organized into a hierarchy.
Java's builtin Class loaders always checks if a class is already loaded before loading it. Reloading the class is therefore not possible using Java's builtin class loaders. To reload a class you will have to implement your own ClassLoader subclass.
I found I was making some assumptions about how our class loader was been created.
I assumed that the class loader would use it's class loader as it's parent (ie getClass().getClassLoader()) but it wasn't
Instead, it was using the SystemClassLoader. This meant that when the child classloader went looking for the shared interface, it couldn't find it (because it was looking at the SystemClassLoader and not the OneJar class loader).
I rectified this by adding CustomClassLoader.class.getClassLoader() to the constructor of our custom class loader
73
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With
