Hey Holger, wow, awesome post with great detailed explanations which I am very interested in because we had a similar problem. I have just one question and like to discuss a small feature request:
On 29.04.2011 13:39, Holger Hoffstätte wrote:
> [first part skipped, let's say we have changed our .so files to
> include $ORIGIN in their run path]
>
> You see, what happens is that the OSGi runtime is at liberty to
> unpack resources from a bundle lazily. This means that simply loading
> a toplevel dependency is not enough, as any other bundle-included
> dependencies may not yet have been unpacked, causing the native
> loader to fail. The fix is easy: simply *pretend* to preload all
> libraries (just like on Windows), but ignore any
> UnsatisfiedLinkErrors - and then load the JNI stubs.
I've read chapter 3.9 "Loading Native Code Libraries" in the OSGi spec
again and it seems the framework is not required to unpack all of a
bundle's native libs into the same directory. But the procedure you
describe relies on this, doesn't it?
BTW: The spec says:
It is not uncommon that native code libraries have dependencies on other
native code libraries. This specification does not support these
dependencies, it is assumed that native libraries delivered in bundles
should not rely on other native libraries.
Now the feature request I like to discuss:
What if felix (or even better the OSGi spec) would recognize a new
directive in the nativecode clause, lets call it "grouping", with this
semantics:
grouping=false
this is the default and it doesn't do anything
grouping=true
this requires the framework to
* uncompress *all* native libs in this nativecode clause as soon as
the *first* of these libs is needed by System.loadLibrary()
* uncompress them into the same directory
This will make the "pretend to preload" hack needless and although I
didn't have a look at the felix code I guess it will be easy to implement.
I am very interested in your opinion on this.
Daniel Faber
signature.asc
Description: OpenPGP digital signature
