On Sat, Sep 17, 2016 at 7:39 PM, David Jencks
<david_jen...@yahoo.com.invalid> 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 <ben...@basistech.com> wrote:
>>
>> On Sat, Sep 17, 2016 at 7:05 PM, David Jencks
>> <david_jen...@yahoo.com.invalid <mailto:david_jen...@yahoo.com.invalid>> 
>> 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 <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
>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscr...@felix.apache.org 
>> <mailto:users-unsubscr...@felix.apache.org>
>> For additional commands, e-mail: users-h...@felix.apache.org 
>> <mailto: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