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]<mailto:[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]<mailto:[email protected]>] Envoyé : mardi 6 octobre 2015 17:06 À : [email protected]<mailto:[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]<mailto:[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]<mailto:[email protected]>] Envoyé : lundi 5 octobre 2015 20:39 À : [email protected]<mailto:[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?
