Adrian Brock wrote:
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().
I'll double check this, but IIUC the library itself
is listed in some higher classloader and never purged
from there.
There are issues on some operating systems thta don't
support loading native code twice.
Or unloading. Think that's why JVM plays safe
and makes that 'run once' on all systems.
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.
That's why I'm trying to resolve this.
I cannot actually use the provided classloader for
those kind of modules. They need the interceptor
that will actually decide how to deploy each sub component.
> 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.
Right, and I'd like to create something that
will be usable actually. If the library has
dependencies with that you still need library
path. Even now with jboss-native I created
library dependency list, so I load libraries
in reverse dependency order.
Thanks for giving me some clues. I'll poke in
the existing source, and see how to implement
some thin interceptor.
Regards
--
^(TM)