On Sat, Sep 17, 2016 at 7:39 PM, David Jencks <[email protected]> wrote: > Ah, I didn’t read your first post closely enough….. IIUC your code is loading > the native library, you are not using OSGI native code support? > > Can you modify things to use OSGI native code support?
To do that, I'd need to make about the same set of arrangements. The code has to remain deliverable as a non-OSGi SDK. One way or the other, I'd have to change the plumbing that calls System.load. > > david jencks > >> On Sep 17, 2016, at 4:16 PM, Benson Margulies <[email protected]> wrote: >> >> On Sat, Sep 17, 2016 at 7:05 PM, David Jencks >> <[email protected] <mailto:[email protected]>> >> wrote: >>> I have no idea what I’m talking about, but I had the vague idea that osgi >>> frameworks get around this by copying the native library to a new, unique, >>> location each time the bundle[revision] starts. The link into your local >>> maven repo doesn’t seem like it’s native code that’s actually in a bundle. >>> Do you have any idea how this path relates to your bundle containing the >>> native code? >> >> That makes a great deal of sense. In our case, the native code is not >> in Maven at all; it's sitting in an outboard product installation >> directory along with 100 tons of NLP models and dictionaries. >> >> However, I'm trying to build something that someone else embeds into >> an arbitrary Java application (and I launch the OSGi framework for >> them). So, getting the temporary directory into java.library.path is >> not going to be straightforward. Options I see include simply changing >> the filename but using the same directory, or changing the Java code >> to know how to call System.load (which takes a pathname) instead of >> System.loadLibrary (which looks in java.library.path). >> >>> >>> david jencks >>> >>>> On Sep 17, 2016, at 3:57 PM, Benson Margulies <[email protected]> wrote: >>>> >>>> Has anyone out there succeeded shutting down the Felix container and >>>> having the classloaders GC to the point where native classes are no >>>> longer loaded, so that the same JVM can then start a new framework and >>>> again load the same native classes? >>>> >>>> To be a bit more precise, I have a bundle that includes some native >>>> classes. I start the framework, load and start this bundle, and it >>>> does the System.loadLibrary to load up these classes. >>>> >>>> I shut down the framework, and try again, and get: >>>> >>>> 18:51:39.140 [Thread-4] ERROR r.1.4.0.201609171300 - >>>> [com.basistech.ws.worker.core.Worker(8)] The activate method has >>>> thrown an exception >>>> java.lang.UnsatisfiedLinkError: Native Library >>>> /Users/benson/.m2/repository/bt/rosapi/roots/native/7.14.100.0/rlp/lib/amd64-darwin11-xcode4/libbtnamesutiljni.dylib >>>> already loaded in another classloader >>>> >>>> My vague sense is that it's somewhere between difficult and impossible >>>> to get native code cleaned up enough to make this work, but I wondered >>>> if anyone else had succeeded using Felix. >>>> >>>> --------------------------------------------------------------------- >>>> To unsubscribe, e-mail: [email protected] >>>> For additional commands, e-mail: [email protected] >>>> >>> >>> >>> --------------------------------------------------------------------- >>> To unsubscribe, e-mail: [email protected] >>> For additional commands, e-mail: [email protected] >>> >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: [email protected] >> <mailto:[email protected]> >> For additional commands, e-mail: [email protected] >> <mailto:[email protected]> --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
