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