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 URLClassloader
s 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)
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 theSystemClassLoader
and not the OneJar class loader).I rectified this by adding
CustomClassLoader.class.getClassLoader()
to the constructor of our custom class loader