You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@felix.apache.org by Benson Margulies <be...@basistech.com> on 2016/09/17 22:57:22 UTC
JNI, classloaders, framework shutdown
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-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org
Re: JNI, classloaders, framework shutdown
Posted by Benson Margulies <be...@basistech.com>.
On Sat, Sep 17, 2016 at 7:39 PM, David Jencks
<da...@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 <be...@basistech.com> wrote:
>>
>> On Sat, Sep 17, 2016 at 7:05 PM, David Jencks
>> <david_jencks@yahoo.com.invalid <ma...@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 <be...@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-unsubscribe@felix.apache.org
>>>> For additional commands, e-mail: users-help@felix.apache.org
>>>>
>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
>>> For additional commands, e-mail: users-help@felix.apache.org
>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org <ma...@felix.apache.org>
>> For additional commands, e-mail: users-help@felix.apache.org <ma...@felix.apache.org>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org
Re: JNI, classloaders, framework shutdown
Posted by David Jencks <da...@yahoo.com.INVALID>.
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?
david jencks
> On Sep 17, 2016, at 4:16 PM, Benson Margulies <be...@basistech.com> wrote:
>
> On Sat, Sep 17, 2016 at 7:05 PM, David Jencks
> <david_jencks@yahoo.com.invalid <ma...@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 <be...@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-unsubscribe@felix.apache.org
>>> For additional commands, e-mail: users-help@felix.apache.org
>>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
>> For additional commands, e-mail: users-help@felix.apache.org
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org <ma...@felix.apache.org>
> For additional commands, e-mail: users-help@felix.apache.org <ma...@felix.apache.org>
Re: JNI, classloaders, framework shutdown
Posted by Benson Margulies <be...@basistech.com>.
On Sat, Sep 17, 2016 at 7:05 PM, David Jencks
<da...@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 <be...@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-unsubscribe@felix.apache.org
>> For additional commands, e-mail: users-help@felix.apache.org
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
> For additional commands, e-mail: users-help@felix.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org
Re: JNI, classloaders, framework shutdown
Posted by David Jencks <da...@yahoo.com.INVALID>.
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 <be...@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-unsubscribe@felix.apache.org
> For additional commands, e-mail: users-help@felix.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org