You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@geronimo.apache.org by Juergen Weber <we...@gmail.com> on 2009/01/16 13:40:55 UTC

JNI and classloaders on Restart

A given native library cannot be loaded by more than one classloader.
(http://java.sun.com/docs/books/jni/html/design.html -> 11.2.4)

So if a Geronimo application, that uses JNI, is restarted, the new
classloader cannot load the library and gets java.lang.UnsatisfiedLinkError:
xx (Library is already loaded in another ClassLoader)

But what if you let the JNI be loaded from a different, non restartable
classloader?
http://cwiki.apache.org/GMOxDOC22/classloading.html
"Plugins become parents of the classloader whereas jars become available
directly in the classloader. "

Does that mean, that a jar in the repository is within the thrown away
classloader whereas a jar in a plugin is not? Then loading a DLL from a
plugin would be the solution to load a native library from a non-restartable
classloader, wouldn't it?

Thanks,
Juergen
-- 
View this message in context: http://www.nabble.com/JNI-and-classloaders-on-Restart-tp21498531s134p21498531.html
Sent from the Apache Geronimo - Users mailing list archive at Nabble.com.


Re: JNI and classloaders on Restart

Posted by Kevan Miller <ke...@gmail.com>.
On Jan 16, 2009, at 7:40 AM, Juergen Weber wrote:

>
> A given native library cannot be loaded by more than one classloader.
> (http://java.sun.com/docs/books/jni/html/design.html -> 11.2.4)
>
> So if a Geronimo application, that uses JNI, is restarted, the new
> classloader cannot load the library and gets  
> java.lang.UnsatisfiedLinkError:
> xx (Library is already loaded in another ClassLoader)
>
> But what if you let the JNI be loaded from a different, non  
> restartable
> classloader?
> http://cwiki.apache.org/GMOxDOC22/classloading.html
> "Plugins become parents of the classloader whereas jars become  
> available
> directly in the classloader. "

Right. A plugin dependency means that the given plugin (ClassLoader)  
must exist and will become a ClassLoader parent of the new plugin  
(ClassLoader) being defined. Jar dependencies define the jars which  
will be searched by the new ClassLoader.

>
> Does that mean, that a jar in the repository is within the thrown away
> classloader whereas a jar in a plugin is not? Then loading a DLL  
> from a
> plugin would be the solution to load a native library from a non- 
> restartable
> classloader, wouldn't it?

Correct. Operations on a given plugin (e.g. start/stop) will affect  
the plugin and any children of the plugin (if you stop a plugin, then  
any children of that plugin must also be stopped). Operations on a  
plugin will not affect the parents of that plugin.

So, you want to define a Plugin A with your JNI libraries. And a  
plugin B with a dependency on plugin A. You should now be able to  
restart B to your hearts content...

--kevan