yeah, as i said, if you want to have a solution that doesn't depend on
specific framework behaviour all you can do is the approach i outlined
before (i.e., extract the libs yourself and a do a System.load()).

However, the "extract all libs on first request" was the default
behaviour of felix for a long time for exactly this usecase. However,
we at one point of time lost it during a refactoring. For now, either
do the "extract yourself" or use the load all libs and ignore problems
and than load the toplevel one (which still depends on the framework
as it needs to extract all libs into the same folder - which felix
does and iirc equinox as well).



On Fri, Apr 29, 2011 at 4:31 PM, Daniel Faber <> wrote:
> 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

Karl Pauls

To unsubscribe, e-mail:
For additional commands, e-mail:

Reply via email to