On Fri, 2008-10-17 at 11:06 +0200, Mladen Turk wrote:
Next thing are partial deployments, where pre-loader
would need to figure out if the previous package is already
installed (redeployment without reboot) in which case
the versioning of the components would either allow
to continue doing nothing or refuse to load until
reboot is done. The second is common behavior now if a
package contains native library references cause they
are all referenced in system classloader regardless of
actual classloader used (and that is what I wish to
resolve basically; packing java and native code inside
archive and make everything plug-and-play).
That's not true. The native libraries belong to
the classloader whose class did System.loadLibrary().
There are issues on some operating systems thta don't
support loading native code twice.
Hotdeploying native code becomes a lottery because
the native code is unloaded "at random" by the GC
at some point after the classloader becomes unreferenced.
There is
Java Module API JSR-227 (for Java7 thought)
and it defines the native libraries as resource concept,
but since (according to the spec) it'll forward the
System.loadLibrary() to the defining class loader of
the calling class the issue will still remain.
That's just a change packaging convention similar
to what OSGi does where the jar contains
the native code instead of having to put the dll(s) on the
library path.
Does this make any sense?
Need some theory on how for example I could write
a code that would get notified when my .jar get
loaded and unloaded by defining classloader.
Since there's no module classloading API (has to be generic)
I can use (eg. a simple URLClassLoader) I suppose
I'll need some voodoo for that :)
Regards
--
xxxxxxxxxxxxxxxxxxxxxxxxxxxx
Adrian Brock
Chief Scientist
JBoss, a division of Red Hat
xxxxxxxxxxxxxxxxxxxxxxxxxxxx