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? > > >
