Hi guys, for OSGi in general there is a little rule-of-thumb about native libs. If they are dynamically linked to other libs, which aren't part of the std. LD_LIBRARY_PATH but part of your application, that won't work good. For one single reason. If you update a bundle, the old classloader will go away, but the library will be kept, so actually your new bundle will be installed with a "new" lib in it with a "new" name. Therefore only one-statically linked lib (which might have relations to std. libs in LD_LIBRARY_PATH) can be used. So bringing it down to the point you are right now. As long as you only have dynamic libs you need to find out how to use those, cause instances always will use the lib folder of the root karaf, that's by design. So you actually need to manually install new Karafs on the same machine for your use-case.
If you have the possibility to run with a static lib, then you can have one single JNI/Java/service bundle for your "native" service. In the end due to "dll"s JNA will not help any further as it's not keeping away that issue of dynamically loading other libraries when needed. regards, Achim 2015-10-08 9:58 GMT+02:00 CLEMENT Jean-Philippe < [email protected]>: > I wish I could have more time to go deeper… did you take a glance at JNA? > > > > JP > > > > [@@ OPEN @@] > > > > *De :* craig niles [mailto:[email protected]] > *Envoyé :* mercredi 7 octobre 2015 17:09 > > *À :* [email protected] > *Objet :* Re: Karaf instances and native libs > > > > The primary problem I was having is that the JVM isn't able to load > transitive native dependencies--i.e., it isn't a monolithic native > library. When loading the library through the OSGi mechanism > (Bundle-NativeCode) it can find the main .so/.dll, but will fail because > some other native dependency that is included with it isn't available. > Even when specifying all the dependencies manually this way it fails. This > is why I wanted to have the libs available through LD_LIBRARY_PATH--its the > only sure way I've found to get them to load. The other problem is that > the middle-ware may try to load the native library itself > > If it were the guaranteed case that each middle-ware used one and only one > .so/.dll file, I wouldn't monkey around with LD_LIBRARY_PATH...but I can't > get that guarantee. > > > > I can't have more than one implementation of the middle-ware available in > a process. To get around this I programattically start child karaf > processes and specify which middle-ware they should use with a karaf > feature. Then, the child karaf process communicates with the root using > DOSGi to share information made available through the middle-ware. > > > > I also already have JNI bindings available to me as part of the > middle-ware spec, and they're implemented. I hear you about blueprint--but > the spec for the middle-ware already uses SPI (and its also used internally > in our in-house middle-ware) so I can't get away from SPI all together. > I've used Aries SPIFly to make them available as OSGi services, and that's > working nicely with iPOJO so far. > > Just to give a little perspective, an example implementation of the > middle-ware is here (though we're not using this one, we have an in-house > implementation and also need to support one from another vendor): > > https://github.com/openlvc/portico > > The package hla.rti1516e is the public interface that is implemented: > > > https://github.com/openlvc/portico/tree/master/codebase/src/java/portico/hla/rti1516e > > > > Thanks for the help so far, I appreciate it. > > > > > > On Wed, Oct 7, 2015 at 9:13 AM, CLEMENT Jean-Philippe < > [email protected]> wrote: > > I’m just wondering why you want to extract the native libraries. Karaf & > maven-bundle-plugin native support is really great IMHO. > > > > But I’m not too sure what “simultaneously” means. I will assume you mean > several suppliers running in parallel inside a Karaf instance. > > > > Let’s say you have a “compute” method with several native implementations. > So you may define a Java interface which contains the signature of this > method. Then implement this contract in several classes using a native call. > > > > And then use the whiteboard pattern. As the implementations does have a > common contract, you may expose them as OSGi services as long with their > characteristics (provider name, type, accuracy… whatever). Then the > consumer(s) may retrieve all suppliers, or supplier(s) matching some > characteristics. > > > > PS: Both service publishing and retrieval can be made easy using blueprint > > > > Again this is just a thought. Would it be applicable to your issue? > > > > Regards, > > JP > > > > [@@ OPEN @@] > > > > *De :* craig niles [mailto:[email protected]] > *Envoyé :* mardi 6 octobre 2015 17:06 > *À :* [email protected] > *Objet :* Re: Karaf instances and native libs > > > > Would you mind elaborating a bit on what you mean by this? > > > > On Tue, Oct 6, 2015 at 9:21 AM, CLEMENT Jean-Philippe < > [email protected]> wrote: > > Just a thought, why not wrapping the native libraries and expose them as a > regular OSGi service through an API? > > > > JP > > > > [@@ OPEN @@] > > > > *De :* craig niles [mailto:[email protected]] > *Envoyé :* lundi 5 octobre 2015 20:39 > *À :* [email protected] > *Objet :* Karaf instances and native libs > > > > Hi, > > I have an important piece of middle-ware that depends on native > libraries. I have a requirement to support multiple implementation of this > middle-ware simultaneously. To accomplish this I want to start child karaf > instances from my main process. > > I'm using an extender pattern to detect when a bundle is installed that > provides the middle-ware. When detected, it extracts the required native > libs from the bundle to the instance lib directory (e.g. > $KARAF_HOME/instances/foo-01/lib). > > I've found an issue, however, with the way LD_LIBRARY_PATH is being set > when the instance is started using the instance's start script--the > KARAF_BASE variable isn't set to the instance's directory and > consequentially LD_LIBRARY_PATH doesn't include the instance's lib > directory when ran. This isn't a problem, however, when started with the > instance's karaf script. > > Does anyone have any ideas or guidance on how to handle this? > > > > > -- Apache Member Apache Karaf <http://karaf.apache.org/> Committer & PMC OPS4J Pax Web <http://wiki.ops4j.org/display/paxweb/Pax+Web/> Committer & Project Lead blog <http://notizblog.nierbeck.de/> Co-Author of Apache Karaf Cookbook <http://bit.ly/1ps9rkS> Software Architect / Project Manager / Scrum Master
