Support context class loader in NativeRuntime's closureManager

[btiernay]

In some circumstances it would be useful to replace:

  private final NativeClosureManager closureManager = new NativeClosureManager(this,
            new SignatureTypeMapperAdapter(new DefaultTypeMapper()),
            new AsmClassLoader(ClassLoader.getSystemClassLoader()));

with

  private final NativeClosureManager closureManager = new NativeClosureManager(this,
            new SignatureTypeMapperAdapter(new DefaultTypeMapper()),
            new AsmClassLoader(Thread.currentThread().getContextClassLoader()));

A good example is with Spring Boot's nested jars which have the following restriction:

Launched applications should use Thread.getContextClassLoader() when loading classes (most libraries and frameworks will do this by default). Trying to load nested jar classes via ClassLoader.getSystemClassLoader() will fail.

Please see http://www.javaworld.com/article/2077344/core-java/find-a-way-out-of-the-classloader-maze.html for a good discussion of this.

[btiernay]

I was able to work around this issue by doing the following:

    ClosureManager closureManager = NativeRuntime.getInstance().getClosureManager();
    val classLoader = findField(closureManager.getClass(), "classLoader");
    classLoader.setAccessible(true);
    val asmClassLoader = classLoader.get(closureManager);

    val parent = findField(asmClassLoader.getClass(), "parent");
    parent.setAccessible(true);
    parent.set(asmClassLoader, Thread.currentThread().getContextClassLoader());

[mkristian]

this means when we switch to the context classloader that in OSGi case it can not find its classes since OSGi does not work with context classloader at all.

but probably you are right in the respect that ClassLoader.getSystemClassLoader() is not the right thing. I would say that getClass().getClassLoader() is the better choice which will work when everything is loaded from the context classloader and with the OSGi case as well.

[btiernay]

That would be a better default. Also, would it be possible to make this configurable maybe?

[headius]

See contributed test case in #55.

[neupsh]

Is there any update on this issue? I was trying to use jnr related java library in clojure and when i run the project with boot-clj build tool, it fails to load the class with:

java.lang.ClassNotFoundException: jnr.ffi.provider.jffi.NativeClosureProxy
             java.lang.NoClassDefFoundError: jnr/ffi/provider/jffi/NativeClosureProxy
                 java.lang.RuntimeException: java.lang.NoClassDefFoundError: jnr/ffi/provider/jffi/NativeClosureProxy

This is because, boot-clj runs 'boot-tasks' in 'pods', which are clojure runtimes in single JVM. They are separated by different classloaders and thus the dependencies are tied to these different classloaders. The System ClassLoader does not have any libraries in the classpath and as a result, it fails to load the class.

[mkristian]

will have look into this first thing next year :)

[headius]

Let's try fixing this with getClass().getClassLoader() falling back on ClassLoader.getSystemClassLoader() when that is null. I'll commit that and y'all can test it.

[headius]

I've pushed a fix and will release 2.1.3 shortly.

[gzunino]

This is not enough for OSGi running jnr as bundle, when a closure defines a return type with a Class defined in another bundle. For example:

BundleA > BundleJNR (BundleA depends on BundleJNR)

a callback on BundleA with a return type ClassA, being ClassA a class on BundleA.

JNR tries to load ClassA with the classloader of BundleJNR and fails to do it.

[realPyR3X]

Has this issue been resolved for OSGi? I'm trying to use JavaFS which relies on this library and I continue to get The activate method has thrown an exception

The activate method has thrown an exception java.lang.RuntimeException: java.lang.NoClassDefFoundError: jnr/ffi/provider/jffi/AsmStructByReferenceFromNativeConverter