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
