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). regards, Karl On Fri, Apr 29, 2011 at 4:31 PM, Daniel Faber <m...@daniel-faber.de> 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 karlpa...@gmail.com --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@felix.apache.org For additional commands, e-mail: users-h...@felix.apache.org
