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?

david jencks

> On Sep 17, 2016, at 3:57 PM, Benson Margulies <ben...@basistech.com> 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: users-unsubscr...@felix.apache.org
> For additional commands, e-mail: users-h...@felix.apache.org
> 


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@felix.apache.org
For additional commands, e-mail: users-h...@felix.apache.org

Reply via email to