[jboss-dev] Classloading and partial deployments

[Adrian Brock]

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