You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@felix.apache.org by Irad Dor <ir...@edgeci.com> on 2011/01/18 18:04:59 UTC
karaf not able to extract (and load) native libraries
Hi,
We have a weird problem with native libraries. We've had Native code
working in the past, and for some reason it is not working anymore.
1. We have a bundle with native libraries (specified using maven
Bundle-NativeCode)
2. The .so files appear in the jar file and also in the manifest
3. The native libraries fail to load with the error below, and when I
check the cache - there are no native libraries present in the bundle
directory
4. We use karaf 1.0.0a
The error that we get is below. I also found it as an issue for karaf
2.0.0 but this is not the version I'm using (see:
https://issues.apache.org/jira/browse/FELIX-1580?page=com.atlassian.jira
.plugin.system.issuetabpanels:all-tabpanel)
Please help,
Thanks,
Irad.
java.lang.ArrayIndexOutOfBoundsException: 0
at
org.apache.felix.framework.util.manifestparser.R4Library.match(R4Library
.java:113)
at
org.apache.felix.framework.ModuleImpl$ModuleClassLoader.findLibrary(Modu
leImpl.java:1929)
at java.lang.ClassLoader.loadLibrary(ClassLoader.java:1705)
at java.lang.Runtime.loadLibrary0(Runtime.java:823)
at java.lang.System.loadLibrary(System.java:1028)
at
com.edgeci.lib.reutersanalyser.ReutersPacketAnalyzerInterface.<init>(Reu
tersPacketAnalyzerInterface.java:39)
at
com.edgeci.lib.reutersanalyser.ReutersAnalyser.__InitializePacketInterfa
ce(ReutersAnalyser.java:93)
at
com.edgeci.lib.reutersanalyser.ReutersAnalyser.InitializePacketInterface
(ReutersAnalyser.java)
at
com.edgeci.lib.reutersanalyser.ReutersAnalyser.__InitializePacketInterfa
ce(ReutersAnalyser.java:119)
at
com.edgeci.lib.reutersanalyser.ReutersAnalyser.InitializePacketInterface
(ReutersAnalyser.java)
at
com.edgeci.lib.reutersanalyser.ReutersAnalyser.__validate(ReutersAnalyse
r.java:127)
at
com.edgeci.lib.reutersanalyser.ReutersAnalyser.validate(ReutersAnalyser.
java)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.jav
a:39)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessor
Impl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at org.apache.felix.ipojo.util.Callback.call(Callback.java:235)
at org.apache.felix.ipojo.util.Callback.call(Callback.java:191)
at
org.apache.felix.ipojo.handlers.lifecycle.callback.LifecycleCallback.cal
l(LifecycleCallback.java:86)
at
org.apache.felix.ipojo.handlers.lifecycle.callback.LifecycleCallbackHand
ler.__stateChanged(LifecycleCallbackHandler.java:162)
at
org.apache.felix.ipojo.handlers.lifecycle.callback.LifecycleCallbackHand
ler.stateChanged(LifecycleCallbackHandler.java)
at
org.apache.felix.ipojo.InstanceManager.setState(InstanceManager.java:441
)
at
org.apache.felix.ipojo.InstanceManager.start(InstanceManager.java:322)
at
org.apache.felix.ipojo.ComponentFactory.createInstance(ComponentFactory.
java:155)
at
org.apache.felix.ipojo.IPojoFactory.createComponentInstance(IPojoFactory
.java:301)
at
org.apache.felix.ipojo.IPojoFactory.createComponentInstance(IPojoFactory
.java:238)
at
org.apache.felix.ipojo.IPojoFactory.updated(IPojoFactory.java:625)
at
org.apache.felix.cm.impl.ConfigurationManager$ManagedServiceFactoryUpdat
e.run(ConfigurationManager.java:1279)
at
org.apache.felix.cm.impl.UpdateThread.run(UpdateThread.java:88)
18 14:15:22.452 ERROR [essence-server-server60]
net.VanillaDataServerSocket | Unexpected error for running server
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org
RE: karaf not able to extract (and load) native libraries
Posted by Irad Dor <ir...@edgeci.com>.
Hi Richard,
Thanks! setting the org.osgi.framework.library.extensions to .so seems
to have solved the problem! I had a another problem where the libraries
must be loaded in a specific order, but this now solved once I've
shuffled them.
Many many thanks!
Irad.
-----Original Message-----
From: Richard S. Hall [mailto:heavy@ungoverned.org]
Sent: 18 January 2011 18:28
To: Irad Dor
Cc: users@felix.apache.org; peter lawrey; greg higgins
Subject: Re: karaf not able to extract (and load) native libraries
On 1/18/11 13:12, Irad Dor wrote:
> Thanks Guillaume,
> Richard - I've seen you fixed this issue in 2.0.1 (?) - can you think
of
> any workaround for this that does not include upgrading?
You could try setting the org.osgi.framework.library.extensions
configuration property to a single library extension, I think that might
avoid the issue...try it and let me know.
Looking at this code, I think we still have a bug in it...I will have to
look more closely.
> It is currently hard to upgrade the karaf version since our production
> system is still using 1.0.0 and it was not ported yet (a long
> process)... Any clue why this did not happen in the past but it
happens
> now all of a sudden (what combination of circumstances causes this)?
Not sure why it would show up now. I'd definitely recommend upgrading as
soon as you can...tons of bug fixes and improvements since then.
> Congratulations BTW!!
Thanks.
-> richard
> Many thanks,
> Irad.
>
>
> -----Original Message-----
> From: Guillaume Nodet [mailto:gnodet@gmail.com]
> Sent: 18 January 2011 17:08
> To: users@felix.apache.org
> Subject: Re: karaf not able to extract (and load) native libraries
>
> I'd suggest trying with a recent karaf version (2.1.3 to see if the
> problem
> still exists).
> If it does, please raise an issue on KARAF. Else, you can either
> upgrade,
> or maybe only switch the felix version used inside karaf to a more
> recent
> one.
>
> On Tue, Jan 18, 2011 at 18:04, Irad Dor<ir...@edgeci.com> wrote:
>
>> Hi,
>> We have a weird problem with native libraries. We've had Native code
>> working in the past, and for some reason it is not working anymore.
>>
>> 1. We have a bundle with native libraries (specified using maven
>> Bundle-NativeCode)
>> 2. The .so files appear in the jar file and also in the manifest
>> 3. The native libraries fail to load with the error below, and when I
>> check the cache - there are no native libraries present in the bundle
>> directory
>> 4. We use karaf 1.0.0a
>>
>> The error that we get is below. I also found it as an issue for karaf
>> 2.0.0 but this is not the version I'm using (see:
>>
>
https://issues.apache.org/jira/browse/FELIX-1580?page=com.atlassian.jira
>> .plugin.system.issuetabpanels:all-tabpanel)
>>
>> Please help,
>> Thanks,
>> Irad.
>>
>>
>> java.lang.ArrayIndexOutOfBoundsException: 0
>> at
>>
>
org.apache.felix.framework.util.manifestparser.R4Library.match(R4Library
>> .java:113)
>> at
>>
>
org.apache.felix.framework.ModuleImpl$ModuleClassLoader.findLibrary(Modu
>> leImpl.java:1929)
>> at java.lang.ClassLoader.loadLibrary(ClassLoader.java:1705)
>> at java.lang.Runtime.loadLibrary0(Runtime.java:823)
>> at java.lang.System.loadLibrary(System.java:1028)
>> at
>>
>
com.edgeci.lib.reutersanalyser.ReutersPacketAnalyzerInterface.<init>(Reu
>> tersPacketAnalyzerInterface.java:39)
>> at
>>
>
com.edgeci.lib.reutersanalyser.ReutersAnalyser.__InitializePacketInterfa
>> ce(ReutersAnalyser.java:93)
>> at
>>
>
com.edgeci.lib.reutersanalyser.ReutersAnalyser.InitializePacketInterface
>> (ReutersAnalyser.java)
>> at
>>
>
com.edgeci.lib.reutersanalyser.ReutersAnalyser.__InitializePacketInterfa
>> ce(ReutersAnalyser.java:119)
>> at
>>
>
com.edgeci.lib.reutersanalyser.ReutersAnalyser.InitializePacketInterface
>> (ReutersAnalyser.java)
>> at
>>
>
com.edgeci.lib.reutersanalyser.ReutersAnalyser.__validate(ReutersAnalyse
>> r.java:127)
>> at
>>
>
com.edgeci.lib.reutersanalyser.ReutersAnalyser.validate(ReutersAnalyser.
>> java)
>> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native
Method)
>> at
>>
>
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.jav
>> a:39)
>> at
>>
>
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessor
>> Impl.java:25)
>> at java.lang.reflect.Method.invoke(Method.java:597)
>> at
org.apache.felix.ipojo.util.Callback.call(Callback.java:235)
>> at
org.apache.felix.ipojo.util.Callback.call(Callback.java:191)
>> at
>>
>
org.apache.felix.ipojo.handlers.lifecycle.callback.LifecycleCallback.cal
>> l(LifecycleCallback.java:86)
>> at
>>
>
org.apache.felix.ipojo.handlers.lifecycle.callback.LifecycleCallbackHand
>> ler.__stateChanged(LifecycleCallbackHandler.java:162)
>> at
>>
>
org.apache.felix.ipojo.handlers.lifecycle.callback.LifecycleCallbackHand
>> ler.stateChanged(LifecycleCallbackHandler.java)
>> at
>>
>
org.apache.felix.ipojo.InstanceManager.setState(InstanceManager.java:441
>> )
>> at
>>
org.apache.felix.ipojo.InstanceManager.start(InstanceManager.java:322)
>> at
>>
>
org.apache.felix.ipojo.ComponentFactory.createInstance(ComponentFactory.
>> java:155)
>> at
>>
>
org.apache.felix.ipojo.IPojoFactory.createComponentInstance(IPojoFactory
>> .java:301)
>> at
>>
>
org.apache.felix.ipojo.IPojoFactory.createComponentInstance(IPojoFactory
>> .java:238)
>> at
>> org.apache.felix.ipojo.IPojoFactory.updated(IPojoFactory.java:625)
>> at
>>
>
org.apache.felix.cm.impl.ConfigurationManager$ManagedServiceFactoryUpdat
>> e.run(ConfigurationManager.java:1279)
>> at
>> org.apache.felix.cm.impl.UpdateThread.run(UpdateThread.java:88)
>> 18 14:15:22.452 ERROR [essence-server-server60]
>> net.VanillaDataServerSocket | Unexpected error for running server
>>
>> ---------------------------------------------------------------------
>> 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: karaf not able to extract (and load) native libraries
Posted by "Richard S. Hall" <he...@ungoverned.org>.
On 1/18/11 13:12, Irad Dor wrote:
> Thanks Guillaume,
> Richard - I've seen you fixed this issue in 2.0.1 (?) - can you think of
> any workaround for this that does not include upgrading?
You could try setting the org.osgi.framework.library.extensions
configuration property to a single library extension, I think that might
avoid the issue...try it and let me know.
Looking at this code, I think we still have a bug in it...I will have to
look more closely.
> It is currently hard to upgrade the karaf version since our production
> system is still using 1.0.0 and it was not ported yet (a long
> process)... Any clue why this did not happen in the past but it happens
> now all of a sudden (what combination of circumstances causes this)?
Not sure why it would show up now. I'd definitely recommend upgrading as
soon as you can...tons of bug fixes and improvements since then.
> Congratulations BTW!!
Thanks.
-> richard
> Many thanks,
> Irad.
>
>
> -----Original Message-----
> From: Guillaume Nodet [mailto:gnodet@gmail.com]
> Sent: 18 January 2011 17:08
> To: users@felix.apache.org
> Subject: Re: karaf not able to extract (and load) native libraries
>
> I'd suggest trying with a recent karaf version (2.1.3 to see if the
> problem
> still exists).
> If it does, please raise an issue on KARAF. Else, you can either
> upgrade,
> or maybe only switch the felix version used inside karaf to a more
> recent
> one.
>
> On Tue, Jan 18, 2011 at 18:04, Irad Dor<ir...@edgeci.com> wrote:
>
>> Hi,
>> We have a weird problem with native libraries. We've had Native code
>> working in the past, and for some reason it is not working anymore.
>>
>> 1. We have a bundle with native libraries (specified using maven
>> Bundle-NativeCode)
>> 2. The .so files appear in the jar file and also in the manifest
>> 3. The native libraries fail to load with the error below, and when I
>> check the cache - there are no native libraries present in the bundle
>> directory
>> 4. We use karaf 1.0.0a
>>
>> The error that we get is below. I also found it as an issue for karaf
>> 2.0.0 but this is not the version I'm using (see:
>>
> https://issues.apache.org/jira/browse/FELIX-1580?page=com.atlassian.jira
>> .plugin.system.issuetabpanels:all-tabpanel)
>>
>> Please help,
>> Thanks,
>> Irad.
>>
>>
>> java.lang.ArrayIndexOutOfBoundsException: 0
>> at
>>
> org.apache.felix.framework.util.manifestparser.R4Library.match(R4Library
>> .java:113)
>> at
>>
> org.apache.felix.framework.ModuleImpl$ModuleClassLoader.findLibrary(Modu
>> leImpl.java:1929)
>> at java.lang.ClassLoader.loadLibrary(ClassLoader.java:1705)
>> at java.lang.Runtime.loadLibrary0(Runtime.java:823)
>> at java.lang.System.loadLibrary(System.java:1028)
>> at
>>
> com.edgeci.lib.reutersanalyser.ReutersPacketAnalyzerInterface.<init>(Reu
>> tersPacketAnalyzerInterface.java:39)
>> at
>>
> com.edgeci.lib.reutersanalyser.ReutersAnalyser.__InitializePacketInterfa
>> ce(ReutersAnalyser.java:93)
>> at
>>
> com.edgeci.lib.reutersanalyser.ReutersAnalyser.InitializePacketInterface
>> (ReutersAnalyser.java)
>> at
>>
> com.edgeci.lib.reutersanalyser.ReutersAnalyser.__InitializePacketInterfa
>> ce(ReutersAnalyser.java:119)
>> at
>>
> com.edgeci.lib.reutersanalyser.ReutersAnalyser.InitializePacketInterface
>> (ReutersAnalyser.java)
>> at
>>
> com.edgeci.lib.reutersanalyser.ReutersAnalyser.__validate(ReutersAnalyse
>> r.java:127)
>> at
>>
> com.edgeci.lib.reutersanalyser.ReutersAnalyser.validate(ReutersAnalyser.
>> java)
>> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>> at
>>
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.jav
>> a:39)
>> at
>>
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessor
>> Impl.java:25)
>> at java.lang.reflect.Method.invoke(Method.java:597)
>> at org.apache.felix.ipojo.util.Callback.call(Callback.java:235)
>> at org.apache.felix.ipojo.util.Callback.call(Callback.java:191)
>> at
>>
> org.apache.felix.ipojo.handlers.lifecycle.callback.LifecycleCallback.cal
>> l(LifecycleCallback.java:86)
>> at
>>
> org.apache.felix.ipojo.handlers.lifecycle.callback.LifecycleCallbackHand
>> ler.__stateChanged(LifecycleCallbackHandler.java:162)
>> at
>>
> org.apache.felix.ipojo.handlers.lifecycle.callback.LifecycleCallbackHand
>> ler.stateChanged(LifecycleCallbackHandler.java)
>> at
>>
> org.apache.felix.ipojo.InstanceManager.setState(InstanceManager.java:441
>> )
>> at
>> org.apache.felix.ipojo.InstanceManager.start(InstanceManager.java:322)
>> at
>>
> org.apache.felix.ipojo.ComponentFactory.createInstance(ComponentFactory.
>> java:155)
>> at
>>
> org.apache.felix.ipojo.IPojoFactory.createComponentInstance(IPojoFactory
>> .java:301)
>> at
>>
> org.apache.felix.ipojo.IPojoFactory.createComponentInstance(IPojoFactory
>> .java:238)
>> at
>> org.apache.felix.ipojo.IPojoFactory.updated(IPojoFactory.java:625)
>> at
>>
> org.apache.felix.cm.impl.ConfigurationManager$ManagedServiceFactoryUpdat
>> e.run(ConfigurationManager.java:1279)
>> at
>> org.apache.felix.cm.impl.UpdateThread.run(UpdateThread.java:88)
>> 18 14:15:22.452 ERROR [essence-server-server60]
>> net.VanillaDataServerSocket | Unexpected error for running server
>>
>> ---------------------------------------------------------------------
>> 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: karaf not able to extract (and load) native libraries
Posted by "Richard S. Hall" <he...@ungoverned.org>.
On 1/19/11 8:29, Adam Crain wrote:
> My problem was a misconception about how OSGi handles native libraries. I
> added the System.loadLibrary call to my activator and now everything works
> beautifully.
>
> Someone please verify this is correct:
>
> OSGi only makes sure that the correct library will be available. The loading
> should be done from the bundle activator. Since the loading is done on the
> right classloader, the library gets unloaded automatically when the bundle
> stops.
The System.loadLibrary() need not happen in the activator, but otherwise
you are correct.
-> richard
> thank you!
> Adam
>
> On Tue, Jan 18, 2011 at 1:50 PM, Adam Crain<ac...@greenenergycorp.com>wrote:
>
>> I did a further experiment. If I modify the bundle manifest manually, and
>> mislabel the artifact dependency I get a different error:
>>
>> Error executing command: Could not start bundle
>> mvn:reef/reef-protocol-dnp3/0.0.3-SNAPSHOT in feature(s)
>> reef-0.0.3-SNAPSHOT: Unresolved constraint in bundle reef.protocol-dnp3
>> [82]: Native library does not exist: lib/lucidx32/libdnp3java.so
>>
>> This seems to indicate to me that Karaf (felix?) is evaluating the bundle
>> manifest. With the correct library specified, my application fails when it
>> tries to make the first JNI call.
>>
>> This library works fine if I manually call System.loadLibrary from the
>> activator and I place the .so somewhere in java.library.path.
>>
>> -Adam
>>
>> On Tue, Jan 18, 2011 at 1:29 PM, Adam Crain<ac...@greenenergycorp.com>wrote:
>>
>>> Hi Irad,
>>>
>>> I am having a similar issue right now with Karaf 2.1.3.
>>>
>>> I have a bundle that wants to start using JNI in it's activator. I'm using
>>> the felix-maven-bnd plugin to add the following to my manifest:
>>>
>>> Bundle-NativeCode:
>>> lib/lucidx32/libdnp3java.so.0.9.3;osname=Linux;processor=x86
>>>
>>> The library is in the specified directory in the bundle jar, but karaf
>>> doesn't seem to be loading the library.
>>>
>>> Any ideas how to debug this?
>>>
>>> regards,
>>> Adam Crain
>>>
>>> On Tue, Jan 18, 2011 at 1:12 PM, Irad Dor<ir...@edgeci.com> wrote:
>>>
>>>> Thanks Guillaume,
>>>> Richard - I've seen you fixed this issue in 2.0.1 (?) - can you think of
>>>> any workaround for this that does not include upgrading?
>>>>
>>>> It is currently hard to upgrade the karaf version since our production
>>>> system is still using 1.0.0 and it was not ported yet (a long
>>>> process)... Any clue why this did not happen in the past but it happens
>>>> now all of a sudden (what combination of circumstances causes this)?
>>>>
>>>> Congratulations BTW!!
>>>>
>>>> Many thanks,
>>>> Irad.
>>>>
>>>>
>>>> -----Original Message-----
>>>> From: Guillaume Nodet [mailto:gnodet@gmail.com]
>>>> Sent: 18 January 2011 17:08
>>>> To: users@felix.apache.org
>>>> Subject: Re: karaf not able to extract (and load) native libraries
>>>>
>>>> I'd suggest trying with a recent karaf version (2.1.3 to see if the
>>>> problem
>>>> still exists).
>>>> If it does, please raise an issue on KARAF. Else, you can either
>>>> upgrade,
>>>> or maybe only switch the felix version used inside karaf to a more
>>>> recent
>>>> one.
>>>>
>>>> On Tue, Jan 18, 2011 at 18:04, Irad Dor<ir...@edgeci.com> wrote:
>>>>
>>>>> Hi,
>>>>> We have a weird problem with native libraries. We've had Native code
>>>>> working in the past, and for some reason it is not working anymore.
>>>>>
>>>>> 1. We have a bundle with native libraries (specified using maven
>>>>> Bundle-NativeCode)
>>>>> 2. The .so files appear in the jar file and also in the manifest
>>>>> 3. The native libraries fail to load with the error below, and when I
>>>>> check the cache - there are no native libraries present in the bundle
>>>>> directory
>>>>> 4. We use karaf 1.0.0a
>>>>>
>>>>> The error that we get is below. I also found it as an issue for karaf
>>>>> 2.0.0 but this is not the version I'm using (see:
>>>>>
>>>> https://issues.apache.org/jira/browse/FELIX-1580?page=com.atlassian.jira
>>>>> .plugin.system.issuetabpanels:all-tabpanel)
>>>>>
>>>>> Please help,
>>>>> Thanks,
>>>>> Irad.
>>>>>
>>>>>
>>>>> java.lang.ArrayIndexOutOfBoundsException: 0
>>>>> at
>>>>>
>>>> org.apache.felix.framework.util.manifestparser.R4Library.match(R4Library
>>>>> .java:113)
>>>>> at
>>>>>
>>>> org.apache.felix.framework.ModuleImpl$ModuleClassLoader.findLibrary(Modu
>>>>> leImpl.java:1929)
>>>>> at java.lang.ClassLoader.loadLibrary(ClassLoader.java:1705)
>>>>> at java.lang.Runtime.loadLibrary0(Runtime.java:823)
>>>>> at java.lang.System.loadLibrary(System.java:1028)
>>>>> at
>>>>>
>>>> com.edgeci.lib.reutersanalyser.ReutersPacketAnalyzerInterface.<init>(Reu
>>>>> tersPacketAnalyzerInterface.java:39)
>>>>> at
>>>>>
>>>> com.edgeci.lib.reutersanalyser.ReutersAnalyser.__InitializePacketInterfa
>>>>> ce(ReutersAnalyser.java:93)
>>>>> at
>>>>>
>>>> com.edgeci.lib.reutersanalyser.ReutersAnalyser.InitializePacketInterface
>>>>> (ReutersAnalyser.java)
>>>>> at
>>>>>
>>>> com.edgeci.lib.reutersanalyser.ReutersAnalyser.__InitializePacketInterfa
>>>>> ce(ReutersAnalyser.java:119)
>>>>> at
>>>>>
>>>> com.edgeci.lib.reutersanalyser.ReutersAnalyser.InitializePacketInterface
>>>>> (ReutersAnalyser.java)
>>>>> at
>>>>>
>>>> com.edgeci.lib.reutersanalyser.ReutersAnalyser.__validate(ReutersAnalyse
>>>>> r.java:127)
>>>>> at
>>>>>
>>>> com.edgeci.lib.reutersanalyser.ReutersAnalyser.validate(ReutersAnalyser.
>>>>> java)
>>>>> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>>>>> at
>>>>>
>>>> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.jav
>>>>> a:39)
>>>>> at
>>>>>
>>>> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessor
>>>>> Impl.java:25)
>>>>> at java.lang.reflect.Method.invoke(Method.java:597)
>>>>> at org.apache.felix.ipojo.util.Callback.call(Callback.java:235)
>>>>> at org.apache.felix.ipojo.util.Callback.call(Callback.java:191)
>>>>> at
>>>>>
>>>> org.apache.felix.ipojo.handlers.lifecycle.callback.LifecycleCallback.cal
>>>>> l(LifecycleCallback.java:86)
>>>>> at
>>>>>
>>>> org.apache.felix.ipojo.handlers.lifecycle.callback.LifecycleCallbackHand
>>>>> ler.__stateChanged(LifecycleCallbackHandler.java:162)
>>>>> at
>>>>>
>>>> org.apache.felix.ipojo.handlers.lifecycle.callback.LifecycleCallbackHand
>>>>> ler.stateChanged(LifecycleCallbackHandler.java)
>>>>> at
>>>>>
>>>> org.apache.felix.ipojo.InstanceManager.setState(InstanceManager.java:441
>>>>> )
>>>>> at
>>>>> org.apache.felix.ipojo.InstanceManager.start(InstanceManager.java:322)
>>>>> at
>>>>>
>>>> org.apache.felix.ipojo.ComponentFactory.createInstance(ComponentFactory.
>>>>> java:155)
>>>>> at
>>>>>
>>>> org.apache.felix.ipojo.IPojoFactory.createComponentInstance(IPojoFactory
>>>>> .java:301)
>>>>> at
>>>>>
>>>> org.apache.felix.ipojo.IPojoFactory.createComponentInstance(IPojoFactory
>>>>> .java:238)
>>>>> at
>>>>> org.apache.felix.ipojo.IPojoFactory.updated(IPojoFactory.java:625)
>>>>> at
>>>>>
>>>> org.apache.felix.cm.impl.ConfigurationManager$ManagedServiceFactoryUpdat
>>>>> e.run(ConfigurationManager.java:1279)
>>>>> at
>>>>> org.apache.felix.cm.impl.UpdateThread.run(UpdateThread.java:88)
>>>>> 18 14:15:22.452 ERROR [essence-server-server60]
>>>>> net.VanillaDataServerSocket | Unexpected error for running server
>>>>>
>>>>> ---------------------------------------------------------------------
>>>>> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
>>>>> For additional commands, e-mail: users-help@felix.apache.org
>>>>>
>>>>>
>>>>
>>>> --
>>>> Cheers,
>>>> Guillaume Nodet
>>>> ------------------------
>>>> Blog: http://gnodet.blogspot.com/
>>>> ------------------------
>>>> Open Source SOA
>>>> http://fusesource.com
>>>>
>>>> ---------------------------------------------------------------------
>>>> 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: karaf not able to extract (and load) native libraries
Posted by Adam Crain <ac...@greenenergycorp.com>.
My problem was a misconception about how OSGi handles native libraries. I
added the System.loadLibrary call to my activator and now everything works
beautifully.
Someone please verify this is correct:
OSGi only makes sure that the correct library will be available. The loading
should be done from the bundle activator. Since the loading is done on the
right classloader, the library gets unloaded automatically when the bundle
stops.
thank you!
Adam
On Tue, Jan 18, 2011 at 1:50 PM, Adam Crain <ac...@greenenergycorp.com>wrote:
> I did a further experiment. If I modify the bundle manifest manually, and
> mislabel the artifact dependency I get a different error:
>
> Error executing command: Could not start bundle
> mvn:reef/reef-protocol-dnp3/0.0.3-SNAPSHOT in feature(s)
> reef-0.0.3-SNAPSHOT: Unresolved constraint in bundle reef.protocol-dnp3
> [82]: Native library does not exist: lib/lucidx32/libdnp3java.so
>
> This seems to indicate to me that Karaf (felix?) is evaluating the bundle
> manifest. With the correct library specified, my application fails when it
> tries to make the first JNI call.
>
> This library works fine if I manually call System.loadLibrary from the
> activator and I place the .so somewhere in java.library.path.
>
> -Adam
>
> On Tue, Jan 18, 2011 at 1:29 PM, Adam Crain <ac...@greenenergycorp.com>wrote:
>
>> Hi Irad,
>>
>> I am having a similar issue right now with Karaf 2.1.3.
>>
>> I have a bundle that wants to start using JNI in it's activator. I'm using
>> the felix-maven-bnd plugin to add the following to my manifest:
>>
>> Bundle-NativeCode:
>> lib/lucidx32/libdnp3java.so.0.9.3;osname=Linux;processor=x86
>>
>> The library is in the specified directory in the bundle jar, but karaf
>> doesn't seem to be loading the library.
>>
>> Any ideas how to debug this?
>>
>> regards,
>> Adam Crain
>>
>> On Tue, Jan 18, 2011 at 1:12 PM, Irad Dor <ir...@edgeci.com> wrote:
>>
>>> Thanks Guillaume,
>>> Richard - I've seen you fixed this issue in 2.0.1 (?) - can you think of
>>> any workaround for this that does not include upgrading?
>>>
>>> It is currently hard to upgrade the karaf version since our production
>>> system is still using 1.0.0 and it was not ported yet (a long
>>> process)... Any clue why this did not happen in the past but it happens
>>> now all of a sudden (what combination of circumstances causes this)?
>>>
>>> Congratulations BTW!!
>>>
>>> Many thanks,
>>> Irad.
>>>
>>>
>>> -----Original Message-----
>>> From: Guillaume Nodet [mailto:gnodet@gmail.com]
>>> Sent: 18 January 2011 17:08
>>> To: users@felix.apache.org
>>> Subject: Re: karaf not able to extract (and load) native libraries
>>>
>>> I'd suggest trying with a recent karaf version (2.1.3 to see if the
>>> problem
>>> still exists).
>>> If it does, please raise an issue on KARAF. Else, you can either
>>> upgrade,
>>> or maybe only switch the felix version used inside karaf to a more
>>> recent
>>> one.
>>>
>>> On Tue, Jan 18, 2011 at 18:04, Irad Dor <ir...@edgeci.com> wrote:
>>>
>>> >
>>> > Hi,
>>> > We have a weird problem with native libraries. We've had Native code
>>> > working in the past, and for some reason it is not working anymore.
>>> >
>>> > 1. We have a bundle with native libraries (specified using maven
>>> > Bundle-NativeCode)
>>> > 2. The .so files appear in the jar file and also in the manifest
>>> > 3. The native libraries fail to load with the error below, and when I
>>> > check the cache - there are no native libraries present in the bundle
>>> > directory
>>> > 4. We use karaf 1.0.0a
>>> >
>>> > The error that we get is below. I also found it as an issue for karaf
>>> > 2.0.0 but this is not the version I'm using (see:
>>> >
>>> https://issues.apache.org/jira/browse/FELIX-1580?page=com.atlassian.jira
>>> > .plugin.system.issuetabpanels:all-tabpanel)
>>> >
>>> > Please help,
>>> > Thanks,
>>> > Irad.
>>> >
>>> >
>>> > java.lang.ArrayIndexOutOfBoundsException: 0
>>> > at
>>> >
>>> org.apache.felix.framework.util.manifestparser.R4Library.match(R4Library
>>> > .java:113)
>>> > at
>>> >
>>> org.apache.felix.framework.ModuleImpl$ModuleClassLoader.findLibrary(Modu
>>> > leImpl.java:1929)
>>> > at java.lang.ClassLoader.loadLibrary(ClassLoader.java:1705)
>>> > at java.lang.Runtime.loadLibrary0(Runtime.java:823)
>>> > at java.lang.System.loadLibrary(System.java:1028)
>>> > at
>>> >
>>> com.edgeci.lib.reutersanalyser.ReutersPacketAnalyzerInterface.<init>(Reu
>>> > tersPacketAnalyzerInterface.java:39)
>>> > at
>>> >
>>> com.edgeci.lib.reutersanalyser.ReutersAnalyser.__InitializePacketInterfa
>>> > ce(ReutersAnalyser.java:93)
>>> > at
>>> >
>>> com.edgeci.lib.reutersanalyser.ReutersAnalyser.InitializePacketInterface
>>> > (ReutersAnalyser.java)
>>> > at
>>> >
>>> com.edgeci.lib.reutersanalyser.ReutersAnalyser.__InitializePacketInterfa
>>> > ce(ReutersAnalyser.java:119)
>>> > at
>>> >
>>> com.edgeci.lib.reutersanalyser.ReutersAnalyser.InitializePacketInterface
>>> > (ReutersAnalyser.java)
>>> > at
>>> >
>>> com.edgeci.lib.reutersanalyser.ReutersAnalyser.__validate(ReutersAnalyse
>>> > r.java:127)
>>> > at
>>> >
>>> com.edgeci.lib.reutersanalyser.ReutersAnalyser.validate(ReutersAnalyser.
>>> > java)
>>> > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>>> > at
>>> >
>>> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.jav
>>> > a:39)
>>> > at
>>> >
>>> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessor
>>> > Impl.java:25)
>>> > at java.lang.reflect.Method.invoke(Method.java:597)
>>> > at org.apache.felix.ipojo.util.Callback.call(Callback.java:235)
>>> > at org.apache.felix.ipojo.util.Callback.call(Callback.java:191)
>>> > at
>>> >
>>> org.apache.felix.ipojo.handlers.lifecycle.callback.LifecycleCallback.cal
>>> > l(LifecycleCallback.java:86)
>>> > at
>>> >
>>> org.apache.felix.ipojo.handlers.lifecycle.callback.LifecycleCallbackHand
>>> > ler.__stateChanged(LifecycleCallbackHandler.java:162)
>>> > at
>>> >
>>> org.apache.felix.ipojo.handlers.lifecycle.callback.LifecycleCallbackHand
>>> > ler.stateChanged(LifecycleCallbackHandler.java)
>>> > at
>>> >
>>> org.apache.felix.ipojo.InstanceManager.setState(InstanceManager.java:441
>>> > )
>>> > at
>>> > org.apache.felix.ipojo.InstanceManager.start(InstanceManager.java:322)
>>> > at
>>> >
>>> org.apache.felix.ipojo.ComponentFactory.createInstance(ComponentFactory.
>>> > java:155)
>>> > at
>>> >
>>> org.apache.felix.ipojo.IPojoFactory.createComponentInstance(IPojoFactory
>>> > .java:301)
>>> > at
>>> >
>>> org.apache.felix.ipojo.IPojoFactory.createComponentInstance(IPojoFactory
>>> > .java:238)
>>> > at
>>> > org.apache.felix.ipojo.IPojoFactory.updated(IPojoFactory.java:625)
>>> > at
>>> >
>>> org.apache.felix.cm.impl.ConfigurationManager$ManagedServiceFactoryUpdat
>>> > e.run(ConfigurationManager.java:1279)
>>> > at
>>> > org.apache.felix.cm.impl.UpdateThread.run(UpdateThread.java:88)
>>> > 18 14:15:22.452 ERROR [essence-server-server60]
>>> > net.VanillaDataServerSocket | Unexpected error for running server
>>> >
>>> > ---------------------------------------------------------------------
>>> > To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
>>> > For additional commands, e-mail: users-help@felix.apache.org
>>> >
>>> >
>>>
>>>
>>> --
>>> Cheers,
>>> Guillaume Nodet
>>> ------------------------
>>> Blog: http://gnodet.blogspot.com/
>>> ------------------------
>>> Open Source SOA
>>> http://fusesource.com
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
>>> For additional commands, e-mail: users-help@felix.apache.org
>>>
>>>
>>
>
Re: karaf not able to extract (and load) native libraries
Posted by "Richard S. Hall" <he...@ungoverned.org>.
On 1/18/11 13:50, Adam Crain wrote:
> I did a further experiment. If I modify the bundle manifest manually, and
> mislabel the artifact dependency I get a different error:
>
> Error executing command: Could not start bundle
> mvn:reef/reef-protocol-dnp3/0.0.3-SNAPSHOT in feature(s)
> reef-0.0.3-SNAPSHOT: Unresolved constraint in bundle reef.protocol-dnp3
> [82]: Native library does not exist: lib/lucidx32/libdnp3java.so
>
> This seems to indicate to me that Karaf (felix?) is evaluating the bundle
> manifest. With the correct library specified, my application fails when it
> tries to make the first JNI call.
>
> This library works fine if I manually call System.loadLibrary from the
> activator and I place the .so somewhere in java.library.path.
Again, just send me a reproducible example. Worst case, you could send
me your entire example directory, but just give me the steps to reproduce.
-> richard
> -Adam
>
> On Tue, Jan 18, 2011 at 1:29 PM, Adam Crain<ac...@greenenergycorp.com>wrote:
>
>> Hi Irad,
>>
>> I am having a similar issue right now with Karaf 2.1.3.
>>
>> I have a bundle that wants to start using JNI in it's activator. I'm using
>> the felix-maven-bnd plugin to add the following to my manifest:
>>
>> Bundle-NativeCode:
>> lib/lucidx32/libdnp3java.so.0.9.3;osname=Linux;processor=x86
>>
>> The library is in the specified directory in the bundle jar, but karaf
>> doesn't seem to be loading the library.
>>
>> Any ideas how to debug this?
>>
>> regards,
>> Adam Crain
>>
>> On Tue, Jan 18, 2011 at 1:12 PM, Irad Dor<ir...@edgeci.com> wrote:
>>
>>> Thanks Guillaume,
>>> Richard - I've seen you fixed this issue in 2.0.1 (?) - can you think of
>>> any workaround for this that does not include upgrading?
>>>
>>> It is currently hard to upgrade the karaf version since our production
>>> system is still using 1.0.0 and it was not ported yet (a long
>>> process)... Any clue why this did not happen in the past but it happens
>>> now all of a sudden (what combination of circumstances causes this)?
>>>
>>> Congratulations BTW!!
>>>
>>> Many thanks,
>>> Irad.
>>>
>>>
>>> -----Original Message-----
>>> From: Guillaume Nodet [mailto:gnodet@gmail.com]
>>> Sent: 18 January 2011 17:08
>>> To: users@felix.apache.org
>>> Subject: Re: karaf not able to extract (and load) native libraries
>>>
>>> I'd suggest trying with a recent karaf version (2.1.3 to see if the
>>> problem
>>> still exists).
>>> If it does, please raise an issue on KARAF. Else, you can either
>>> upgrade,
>>> or maybe only switch the felix version used inside karaf to a more
>>> recent
>>> one.
>>>
>>> On Tue, Jan 18, 2011 at 18:04, Irad Dor<ir...@edgeci.com> wrote:
>>>
>>>> Hi,
>>>> We have a weird problem with native libraries. We've had Native code
>>>> working in the past, and for some reason it is not working anymore.
>>>>
>>>> 1. We have a bundle with native libraries (specified using maven
>>>> Bundle-NativeCode)
>>>> 2. The .so files appear in the jar file and also in the manifest
>>>> 3. The native libraries fail to load with the error below, and when I
>>>> check the cache - there are no native libraries present in the bundle
>>>> directory
>>>> 4. We use karaf 1.0.0a
>>>>
>>>> The error that we get is below. I also found it as an issue for karaf
>>>> 2.0.0 but this is not the version I'm using (see:
>>>>
>>> https://issues.apache.org/jira/browse/FELIX-1580?page=com.atlassian.jira
>>>> .plugin.system.issuetabpanels:all-tabpanel)
>>>>
>>>> Please help,
>>>> Thanks,
>>>> Irad.
>>>>
>>>>
>>>> java.lang.ArrayIndexOutOfBoundsException: 0
>>>> at
>>>>
>>> org.apache.felix.framework.util.manifestparser.R4Library.match(R4Library
>>>> .java:113)
>>>> at
>>>>
>>> org.apache.felix.framework.ModuleImpl$ModuleClassLoader.findLibrary(Modu
>>>> leImpl.java:1929)
>>>> at java.lang.ClassLoader.loadLibrary(ClassLoader.java:1705)
>>>> at java.lang.Runtime.loadLibrary0(Runtime.java:823)
>>>> at java.lang.System.loadLibrary(System.java:1028)
>>>> at
>>>>
>>> com.edgeci.lib.reutersanalyser.ReutersPacketAnalyzerInterface.<init>(Reu
>>>> tersPacketAnalyzerInterface.java:39)
>>>> at
>>>>
>>> com.edgeci.lib.reutersanalyser.ReutersAnalyser.__InitializePacketInterfa
>>>> ce(ReutersAnalyser.java:93)
>>>> at
>>>>
>>> com.edgeci.lib.reutersanalyser.ReutersAnalyser.InitializePacketInterface
>>>> (ReutersAnalyser.java)
>>>> at
>>>>
>>> com.edgeci.lib.reutersanalyser.ReutersAnalyser.__InitializePacketInterfa
>>>> ce(ReutersAnalyser.java:119)
>>>> at
>>>>
>>> com.edgeci.lib.reutersanalyser.ReutersAnalyser.InitializePacketInterface
>>>> (ReutersAnalyser.java)
>>>> at
>>>>
>>> com.edgeci.lib.reutersanalyser.ReutersAnalyser.__validate(ReutersAnalyse
>>>> r.java:127)
>>>> at
>>>>
>>> com.edgeci.lib.reutersanalyser.ReutersAnalyser.validate(ReutersAnalyser.
>>>> java)
>>>> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>>>> at
>>>>
>>> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.jav
>>>> a:39)
>>>> at
>>>>
>>> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessor
>>>> Impl.java:25)
>>>> at java.lang.reflect.Method.invoke(Method.java:597)
>>>> at org.apache.felix.ipojo.util.Callback.call(Callback.java:235)
>>>> at org.apache.felix.ipojo.util.Callback.call(Callback.java:191)
>>>> at
>>>>
>>> org.apache.felix.ipojo.handlers.lifecycle.callback.LifecycleCallback.cal
>>>> l(LifecycleCallback.java:86)
>>>> at
>>>>
>>> org.apache.felix.ipojo.handlers.lifecycle.callback.LifecycleCallbackHand
>>>> ler.__stateChanged(LifecycleCallbackHandler.java:162)
>>>> at
>>>>
>>> org.apache.felix.ipojo.handlers.lifecycle.callback.LifecycleCallbackHand
>>>> ler.stateChanged(LifecycleCallbackHandler.java)
>>>> at
>>>>
>>> org.apache.felix.ipojo.InstanceManager.setState(InstanceManager.java:441
>>>> )
>>>> at
>>>> org.apache.felix.ipojo.InstanceManager.start(InstanceManager.java:322)
>>>> at
>>>>
>>> org.apache.felix.ipojo.ComponentFactory.createInstance(ComponentFactory.
>>>> java:155)
>>>> at
>>>>
>>> org.apache.felix.ipojo.IPojoFactory.createComponentInstance(IPojoFactory
>>>> .java:301)
>>>> at
>>>>
>>> org.apache.felix.ipojo.IPojoFactory.createComponentInstance(IPojoFactory
>>>> .java:238)
>>>> at
>>>> org.apache.felix.ipojo.IPojoFactory.updated(IPojoFactory.java:625)
>>>> at
>>>>
>>> org.apache.felix.cm.impl.ConfigurationManager$ManagedServiceFactoryUpdat
>>>> e.run(ConfigurationManager.java:1279)
>>>> at
>>>> org.apache.felix.cm.impl.UpdateThread.run(UpdateThread.java:88)
>>>> 18 14:15:22.452 ERROR [essence-server-server60]
>>>> net.VanillaDataServerSocket | Unexpected error for running server
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
>>>> For additional commands, e-mail: users-help@felix.apache.org
>>>>
>>>>
>>>
>>> --
>>> Cheers,
>>> Guillaume Nodet
>>> ------------------------
>>> Blog: http://gnodet.blogspot.com/
>>> ------------------------
>>> Open Source SOA
>>> http://fusesource.com
>>>
>>> ---------------------------------------------------------------------
>>> 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: karaf not able to extract (and load) native libraries
Posted by Adam Crain <ac...@greenenergycorp.com>.
I did a further experiment. If I modify the bundle manifest manually, and
mislabel the artifact dependency I get a different error:
Error executing command: Could not start bundle
mvn:reef/reef-protocol-dnp3/0.0.3-SNAPSHOT in feature(s)
reef-0.0.3-SNAPSHOT: Unresolved constraint in bundle reef.protocol-dnp3
[82]: Native library does not exist: lib/lucidx32/libdnp3java.so
This seems to indicate to me that Karaf (felix?) is evaluating the bundle
manifest. With the correct library specified, my application fails when it
tries to make the first JNI call.
This library works fine if I manually call System.loadLibrary from the
activator and I place the .so somewhere in java.library.path.
-Adam
On Tue, Jan 18, 2011 at 1:29 PM, Adam Crain <ac...@greenenergycorp.com>wrote:
> Hi Irad,
>
> I am having a similar issue right now with Karaf 2.1.3.
>
> I have a bundle that wants to start using JNI in it's activator. I'm using
> the felix-maven-bnd plugin to add the following to my manifest:
>
> Bundle-NativeCode:
> lib/lucidx32/libdnp3java.so.0.9.3;osname=Linux;processor=x86
>
> The library is in the specified directory in the bundle jar, but karaf
> doesn't seem to be loading the library.
>
> Any ideas how to debug this?
>
> regards,
> Adam Crain
>
> On Tue, Jan 18, 2011 at 1:12 PM, Irad Dor <ir...@edgeci.com> wrote:
>
>> Thanks Guillaume,
>> Richard - I've seen you fixed this issue in 2.0.1 (?) - can you think of
>> any workaround for this that does not include upgrading?
>>
>> It is currently hard to upgrade the karaf version since our production
>> system is still using 1.0.0 and it was not ported yet (a long
>> process)... Any clue why this did not happen in the past but it happens
>> now all of a sudden (what combination of circumstances causes this)?
>>
>> Congratulations BTW!!
>>
>> Many thanks,
>> Irad.
>>
>>
>> -----Original Message-----
>> From: Guillaume Nodet [mailto:gnodet@gmail.com]
>> Sent: 18 January 2011 17:08
>> To: users@felix.apache.org
>> Subject: Re: karaf not able to extract (and load) native libraries
>>
>> I'd suggest trying with a recent karaf version (2.1.3 to see if the
>> problem
>> still exists).
>> If it does, please raise an issue on KARAF. Else, you can either
>> upgrade,
>> or maybe only switch the felix version used inside karaf to a more
>> recent
>> one.
>>
>> On Tue, Jan 18, 2011 at 18:04, Irad Dor <ir...@edgeci.com> wrote:
>>
>> >
>> > Hi,
>> > We have a weird problem with native libraries. We've had Native code
>> > working in the past, and for some reason it is not working anymore.
>> >
>> > 1. We have a bundle with native libraries (specified using maven
>> > Bundle-NativeCode)
>> > 2. The .so files appear in the jar file and also in the manifest
>> > 3. The native libraries fail to load with the error below, and when I
>> > check the cache - there are no native libraries present in the bundle
>> > directory
>> > 4. We use karaf 1.0.0a
>> >
>> > The error that we get is below. I also found it as an issue for karaf
>> > 2.0.0 but this is not the version I'm using (see:
>> >
>> https://issues.apache.org/jira/browse/FELIX-1580?page=com.atlassian.jira
>> > .plugin.system.issuetabpanels:all-tabpanel)
>> >
>> > Please help,
>> > Thanks,
>> > Irad.
>> >
>> >
>> > java.lang.ArrayIndexOutOfBoundsException: 0
>> > at
>> >
>> org.apache.felix.framework.util.manifestparser.R4Library.match(R4Library
>> > .java:113)
>> > at
>> >
>> org.apache.felix.framework.ModuleImpl$ModuleClassLoader.findLibrary(Modu
>> > leImpl.java:1929)
>> > at java.lang.ClassLoader.loadLibrary(ClassLoader.java:1705)
>> > at java.lang.Runtime.loadLibrary0(Runtime.java:823)
>> > at java.lang.System.loadLibrary(System.java:1028)
>> > at
>> >
>> com.edgeci.lib.reutersanalyser.ReutersPacketAnalyzerInterface.<init>(Reu
>> > tersPacketAnalyzerInterface.java:39)
>> > at
>> >
>> com.edgeci.lib.reutersanalyser.ReutersAnalyser.__InitializePacketInterfa
>> > ce(ReutersAnalyser.java:93)
>> > at
>> >
>> com.edgeci.lib.reutersanalyser.ReutersAnalyser.InitializePacketInterface
>> > (ReutersAnalyser.java)
>> > at
>> >
>> com.edgeci.lib.reutersanalyser.ReutersAnalyser.__InitializePacketInterfa
>> > ce(ReutersAnalyser.java:119)
>> > at
>> >
>> com.edgeci.lib.reutersanalyser.ReutersAnalyser.InitializePacketInterface
>> > (ReutersAnalyser.java)
>> > at
>> >
>> com.edgeci.lib.reutersanalyser.ReutersAnalyser.__validate(ReutersAnalyse
>> > r.java:127)
>> > at
>> >
>> com.edgeci.lib.reutersanalyser.ReutersAnalyser.validate(ReutersAnalyser.
>> > java)
>> > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>> > at
>> >
>> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.jav
>> > a:39)
>> > at
>> >
>> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessor
>> > Impl.java:25)
>> > at java.lang.reflect.Method.invoke(Method.java:597)
>> > at org.apache.felix.ipojo.util.Callback.call(Callback.java:235)
>> > at org.apache.felix.ipojo.util.Callback.call(Callback.java:191)
>> > at
>> >
>> org.apache.felix.ipojo.handlers.lifecycle.callback.LifecycleCallback.cal
>> > l(LifecycleCallback.java:86)
>> > at
>> >
>> org.apache.felix.ipojo.handlers.lifecycle.callback.LifecycleCallbackHand
>> > ler.__stateChanged(LifecycleCallbackHandler.java:162)
>> > at
>> >
>> org.apache.felix.ipojo.handlers.lifecycle.callback.LifecycleCallbackHand
>> > ler.stateChanged(LifecycleCallbackHandler.java)
>> > at
>> >
>> org.apache.felix.ipojo.InstanceManager.setState(InstanceManager.java:441
>> > )
>> > at
>> > org.apache.felix.ipojo.InstanceManager.start(InstanceManager.java:322)
>> > at
>> >
>> org.apache.felix.ipojo.ComponentFactory.createInstance(ComponentFactory.
>> > java:155)
>> > at
>> >
>> org.apache.felix.ipojo.IPojoFactory.createComponentInstance(IPojoFactory
>> > .java:301)
>> > at
>> >
>> org.apache.felix.ipojo.IPojoFactory.createComponentInstance(IPojoFactory
>> > .java:238)
>> > at
>> > org.apache.felix.ipojo.IPojoFactory.updated(IPojoFactory.java:625)
>> > at
>> >
>> org.apache.felix.cm.impl.ConfigurationManager$ManagedServiceFactoryUpdat
>> > e.run(ConfigurationManager.java:1279)
>> > at
>> > org.apache.felix.cm.impl.UpdateThread.run(UpdateThread.java:88)
>> > 18 14:15:22.452 ERROR [essence-server-server60]
>> > net.VanillaDataServerSocket | Unexpected error for running server
>> >
>> > ---------------------------------------------------------------------
>> > To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
>> > For additional commands, e-mail: users-help@felix.apache.org
>> >
>> >
>>
>>
>> --
>> Cheers,
>> Guillaume Nodet
>> ------------------------
>> Blog: http://gnodet.blogspot.com/
>> ------------------------
>> Open Source SOA
>> http://fusesource.com
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
>> For additional commands, e-mail: users-help@felix.apache.org
>>
>>
>
Re: karaf not able to extract (and load) native libraries
Posted by Adam Crain <ac...@greenenergycorp.com>.
Hi Irad,
I am having a similar issue right now with Karaf 2.1.3.
I have a bundle that wants to start using JNI in it's activator. I'm using
the felix-maven-bnd plugin to add the following to my manifest:
Bundle-NativeCode:
lib/lucidx32/libdnp3java.so.0.9.3;osname=Linux;processor=x86
The library is in the specified directory in the bundle jar, but karaf
doesn't seem to be loading the library.
Any ideas how to debug this?
regards,
Adam Crain
On Tue, Jan 18, 2011 at 1:12 PM, Irad Dor <ir...@edgeci.com> wrote:
> Thanks Guillaume,
> Richard - I've seen you fixed this issue in 2.0.1 (?) - can you think of
> any workaround for this that does not include upgrading?
>
> It is currently hard to upgrade the karaf version since our production
> system is still using 1.0.0 and it was not ported yet (a long
> process)... Any clue why this did not happen in the past but it happens
> now all of a sudden (what combination of circumstances causes this)?
>
> Congratulations BTW!!
>
> Many thanks,
> Irad.
>
>
> -----Original Message-----
> From: Guillaume Nodet [mailto:gnodet@gmail.com]
> Sent: 18 January 2011 17:08
> To: users@felix.apache.org
> Subject: Re: karaf not able to extract (and load) native libraries
>
> I'd suggest trying with a recent karaf version (2.1.3 to see if the
> problem
> still exists).
> If it does, please raise an issue on KARAF. Else, you can either
> upgrade,
> or maybe only switch the felix version used inside karaf to a more
> recent
> one.
>
> On Tue, Jan 18, 2011 at 18:04, Irad Dor <ir...@edgeci.com> wrote:
>
> >
> > Hi,
> > We have a weird problem with native libraries. We've had Native code
> > working in the past, and for some reason it is not working anymore.
> >
> > 1. We have a bundle with native libraries (specified using maven
> > Bundle-NativeCode)
> > 2. The .so files appear in the jar file and also in the manifest
> > 3. The native libraries fail to load with the error below, and when I
> > check the cache - there are no native libraries present in the bundle
> > directory
> > 4. We use karaf 1.0.0a
> >
> > The error that we get is below. I also found it as an issue for karaf
> > 2.0.0 but this is not the version I'm using (see:
> >
> https://issues.apache.org/jira/browse/FELIX-1580?page=com.atlassian.jira
> > .plugin.system.issuetabpanels:all-tabpanel)
> >
> > Please help,
> > Thanks,
> > Irad.
> >
> >
> > java.lang.ArrayIndexOutOfBoundsException: 0
> > at
> >
> org.apache.felix.framework.util.manifestparser.R4Library.match(R4Library
> > .java:113)
> > at
> >
> org.apache.felix.framework.ModuleImpl$ModuleClassLoader.findLibrary(Modu
> > leImpl.java:1929)
> > at java.lang.ClassLoader.loadLibrary(ClassLoader.java:1705)
> > at java.lang.Runtime.loadLibrary0(Runtime.java:823)
> > at java.lang.System.loadLibrary(System.java:1028)
> > at
> >
> com.edgeci.lib.reutersanalyser.ReutersPacketAnalyzerInterface.<init>(Reu
> > tersPacketAnalyzerInterface.java:39)
> > at
> >
> com.edgeci.lib.reutersanalyser.ReutersAnalyser.__InitializePacketInterfa
> > ce(ReutersAnalyser.java:93)
> > at
> >
> com.edgeci.lib.reutersanalyser.ReutersAnalyser.InitializePacketInterface
> > (ReutersAnalyser.java)
> > at
> >
> com.edgeci.lib.reutersanalyser.ReutersAnalyser.__InitializePacketInterfa
> > ce(ReutersAnalyser.java:119)
> > at
> >
> com.edgeci.lib.reutersanalyser.ReutersAnalyser.InitializePacketInterface
> > (ReutersAnalyser.java)
> > at
> >
> com.edgeci.lib.reutersanalyser.ReutersAnalyser.__validate(ReutersAnalyse
> > r.java:127)
> > at
> >
> com.edgeci.lib.reutersanalyser.ReutersAnalyser.validate(ReutersAnalyser.
> > java)
> > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> > at
> >
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.jav
> > a:39)
> > at
> >
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessor
> > Impl.java:25)
> > at java.lang.reflect.Method.invoke(Method.java:597)
> > at org.apache.felix.ipojo.util.Callback.call(Callback.java:235)
> > at org.apache.felix.ipojo.util.Callback.call(Callback.java:191)
> > at
> >
> org.apache.felix.ipojo.handlers.lifecycle.callback.LifecycleCallback.cal
> > l(LifecycleCallback.java:86)
> > at
> >
> org.apache.felix.ipojo.handlers.lifecycle.callback.LifecycleCallbackHand
> > ler.__stateChanged(LifecycleCallbackHandler.java:162)
> > at
> >
> org.apache.felix.ipojo.handlers.lifecycle.callback.LifecycleCallbackHand
> > ler.stateChanged(LifecycleCallbackHandler.java)
> > at
> >
> org.apache.felix.ipojo.InstanceManager.setState(InstanceManager.java:441
> > )
> > at
> > org.apache.felix.ipojo.InstanceManager.start(InstanceManager.java:322)
> > at
> >
> org.apache.felix.ipojo.ComponentFactory.createInstance(ComponentFactory.
> > java:155)
> > at
> >
> org.apache.felix.ipojo.IPojoFactory.createComponentInstance(IPojoFactory
> > .java:301)
> > at
> >
> org.apache.felix.ipojo.IPojoFactory.createComponentInstance(IPojoFactory
> > .java:238)
> > at
> > org.apache.felix.ipojo.IPojoFactory.updated(IPojoFactory.java:625)
> > at
> >
> org.apache.felix.cm.impl.ConfigurationManager$ManagedServiceFactoryUpdat
> > e.run(ConfigurationManager.java:1279)
> > at
> > org.apache.felix.cm.impl.UpdateThread.run(UpdateThread.java:88)
> > 18 14:15:22.452 ERROR [essence-server-server60]
> > net.VanillaDataServerSocket | Unexpected error for running server
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
> > For additional commands, e-mail: users-help@felix.apache.org
> >
> >
>
>
> --
> Cheers,
> Guillaume Nodet
> ------------------------
> Blog: http://gnodet.blogspot.com/
> ------------------------
> Open Source SOA
> http://fusesource.com
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
> For additional commands, e-mail: users-help@felix.apache.org
>
>
RE: karaf not able to extract (and load) native libraries
Posted by Irad Dor <ir...@edgeci.com>.
Thanks Guillaume,
Richard - I've seen you fixed this issue in 2.0.1 (?) - can you think of
any workaround for this that does not include upgrading?
It is currently hard to upgrade the karaf version since our production
system is still using 1.0.0 and it was not ported yet (a long
process)... Any clue why this did not happen in the past but it happens
now all of a sudden (what combination of circumstances causes this)?
Congratulations BTW!!
Many thanks,
Irad.
-----Original Message-----
From: Guillaume Nodet [mailto:gnodet@gmail.com]
Sent: 18 January 2011 17:08
To: users@felix.apache.org
Subject: Re: karaf not able to extract (and load) native libraries
I'd suggest trying with a recent karaf version (2.1.3 to see if the
problem
still exists).
If it does, please raise an issue on KARAF. Else, you can either
upgrade,
or maybe only switch the felix version used inside karaf to a more
recent
one.
On Tue, Jan 18, 2011 at 18:04, Irad Dor <ir...@edgeci.com> wrote:
>
> Hi,
> We have a weird problem with native libraries. We've had Native code
> working in the past, and for some reason it is not working anymore.
>
> 1. We have a bundle with native libraries (specified using maven
> Bundle-NativeCode)
> 2. The .so files appear in the jar file and also in the manifest
> 3. The native libraries fail to load with the error below, and when I
> check the cache - there are no native libraries present in the bundle
> directory
> 4. We use karaf 1.0.0a
>
> The error that we get is below. I also found it as an issue for karaf
> 2.0.0 but this is not the version I'm using (see:
>
https://issues.apache.org/jira/browse/FELIX-1580?page=com.atlassian.jira
> .plugin.system.issuetabpanels:all-tabpanel)
>
> Please help,
> Thanks,
> Irad.
>
>
> java.lang.ArrayIndexOutOfBoundsException: 0
> at
>
org.apache.felix.framework.util.manifestparser.R4Library.match(R4Library
> .java:113)
> at
>
org.apache.felix.framework.ModuleImpl$ModuleClassLoader.findLibrary(Modu
> leImpl.java:1929)
> at java.lang.ClassLoader.loadLibrary(ClassLoader.java:1705)
> at java.lang.Runtime.loadLibrary0(Runtime.java:823)
> at java.lang.System.loadLibrary(System.java:1028)
> at
>
com.edgeci.lib.reutersanalyser.ReutersPacketAnalyzerInterface.<init>(Reu
> tersPacketAnalyzerInterface.java:39)
> at
>
com.edgeci.lib.reutersanalyser.ReutersAnalyser.__InitializePacketInterfa
> ce(ReutersAnalyser.java:93)
> at
>
com.edgeci.lib.reutersanalyser.ReutersAnalyser.InitializePacketInterface
> (ReutersAnalyser.java)
> at
>
com.edgeci.lib.reutersanalyser.ReutersAnalyser.__InitializePacketInterfa
> ce(ReutersAnalyser.java:119)
> at
>
com.edgeci.lib.reutersanalyser.ReutersAnalyser.InitializePacketInterface
> (ReutersAnalyser.java)
> at
>
com.edgeci.lib.reutersanalyser.ReutersAnalyser.__validate(ReutersAnalyse
> r.java:127)
> at
>
com.edgeci.lib.reutersanalyser.ReutersAnalyser.validate(ReutersAnalyser.
> java)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
>
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.jav
> a:39)
> at
>
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessor
> Impl.java:25)
> at java.lang.reflect.Method.invoke(Method.java:597)
> at org.apache.felix.ipojo.util.Callback.call(Callback.java:235)
> at org.apache.felix.ipojo.util.Callback.call(Callback.java:191)
> at
>
org.apache.felix.ipojo.handlers.lifecycle.callback.LifecycleCallback.cal
> l(LifecycleCallback.java:86)
> at
>
org.apache.felix.ipojo.handlers.lifecycle.callback.LifecycleCallbackHand
> ler.__stateChanged(LifecycleCallbackHandler.java:162)
> at
>
org.apache.felix.ipojo.handlers.lifecycle.callback.LifecycleCallbackHand
> ler.stateChanged(LifecycleCallbackHandler.java)
> at
>
org.apache.felix.ipojo.InstanceManager.setState(InstanceManager.java:441
> )
> at
> org.apache.felix.ipojo.InstanceManager.start(InstanceManager.java:322)
> at
>
org.apache.felix.ipojo.ComponentFactory.createInstance(ComponentFactory.
> java:155)
> at
>
org.apache.felix.ipojo.IPojoFactory.createComponentInstance(IPojoFactory
> .java:301)
> at
>
org.apache.felix.ipojo.IPojoFactory.createComponentInstance(IPojoFactory
> .java:238)
> at
> org.apache.felix.ipojo.IPojoFactory.updated(IPojoFactory.java:625)
> at
>
org.apache.felix.cm.impl.ConfigurationManager$ManagedServiceFactoryUpdat
> e.run(ConfigurationManager.java:1279)
> at
> org.apache.felix.cm.impl.UpdateThread.run(UpdateThread.java:88)
> 18 14:15:22.452 ERROR [essence-server-server60]
> net.VanillaDataServerSocket | Unexpected error for running server
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
> For additional commands, e-mail: users-help@felix.apache.org
>
>
--
Cheers,
Guillaume Nodet
------------------------
Blog: http://gnodet.blogspot.com/
------------------------
Open Source SOA
http://fusesource.com
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org
Re: karaf not able to extract (and load) native libraries
Posted by Guillaume Nodet <gn...@gmail.com>.
I'd suggest trying with a recent karaf version (2.1.3 to see if the problem
still exists).
If it does, please raise an issue on KARAF. Else, you can either upgrade,
or maybe only switch the felix version used inside karaf to a more recent
one.
On Tue, Jan 18, 2011 at 18:04, Irad Dor <ir...@edgeci.com> wrote:
>
> Hi,
> We have a weird problem with native libraries. We've had Native code
> working in the past, and for some reason it is not working anymore.
>
> 1. We have a bundle with native libraries (specified using maven
> Bundle-NativeCode)
> 2. The .so files appear in the jar file and also in the manifest
> 3. The native libraries fail to load with the error below, and when I
> check the cache - there are no native libraries present in the bundle
> directory
> 4. We use karaf 1.0.0a
>
> The error that we get is below. I also found it as an issue for karaf
> 2.0.0 but this is not the version I'm using (see:
> https://issues.apache.org/jira/browse/FELIX-1580?page=com.atlassian.jira
> .plugin.system.issuetabpanels:all-tabpanel)
>
> Please help,
> Thanks,
> Irad.
>
>
> java.lang.ArrayIndexOutOfBoundsException: 0
> at
> org.apache.felix.framework.util.manifestparser.R4Library.match(R4Library
> .java:113)
> at
> org.apache.felix.framework.ModuleImpl$ModuleClassLoader.findLibrary(Modu
> leImpl.java:1929)
> at java.lang.ClassLoader.loadLibrary(ClassLoader.java:1705)
> at java.lang.Runtime.loadLibrary0(Runtime.java:823)
> at java.lang.System.loadLibrary(System.java:1028)
> at
> com.edgeci.lib.reutersanalyser.ReutersPacketAnalyzerInterface.<init>(Reu
> tersPacketAnalyzerInterface.java:39)
> at
> com.edgeci.lib.reutersanalyser.ReutersAnalyser.__InitializePacketInterfa
> ce(ReutersAnalyser.java:93)
> at
> com.edgeci.lib.reutersanalyser.ReutersAnalyser.InitializePacketInterface
> (ReutersAnalyser.java)
> at
> com.edgeci.lib.reutersanalyser.ReutersAnalyser.__InitializePacketInterfa
> ce(ReutersAnalyser.java:119)
> at
> com.edgeci.lib.reutersanalyser.ReutersAnalyser.InitializePacketInterface
> (ReutersAnalyser.java)
> at
> com.edgeci.lib.reutersanalyser.ReutersAnalyser.__validate(ReutersAnalyse
> r.java:127)
> at
> com.edgeci.lib.reutersanalyser.ReutersAnalyser.validate(ReutersAnalyser.
> java)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.jav
> a:39)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessor
> Impl.java:25)
> at java.lang.reflect.Method.invoke(Method.java:597)
> at org.apache.felix.ipojo.util.Callback.call(Callback.java:235)
> at org.apache.felix.ipojo.util.Callback.call(Callback.java:191)
> at
> org.apache.felix.ipojo.handlers.lifecycle.callback.LifecycleCallback.cal
> l(LifecycleCallback.java:86)
> at
> org.apache.felix.ipojo.handlers.lifecycle.callback.LifecycleCallbackHand
> ler.__stateChanged(LifecycleCallbackHandler.java:162)
> at
> org.apache.felix.ipojo.handlers.lifecycle.callback.LifecycleCallbackHand
> ler.stateChanged(LifecycleCallbackHandler.java)
> at
> org.apache.felix.ipojo.InstanceManager.setState(InstanceManager.java:441
> )
> at
> org.apache.felix.ipojo.InstanceManager.start(InstanceManager.java:322)
> at
> org.apache.felix.ipojo.ComponentFactory.createInstance(ComponentFactory.
> java:155)
> at
> org.apache.felix.ipojo.IPojoFactory.createComponentInstance(IPojoFactory
> .java:301)
> at
> org.apache.felix.ipojo.IPojoFactory.createComponentInstance(IPojoFactory
> .java:238)
> at
> org.apache.felix.ipojo.IPojoFactory.updated(IPojoFactory.java:625)
> at
> org.apache.felix.cm.impl.ConfigurationManager$ManagedServiceFactoryUpdat
> e.run(ConfigurationManager.java:1279)
> at
> org.apache.felix.cm.impl.UpdateThread.run(UpdateThread.java:88)
> 18 14:15:22.452 ERROR [essence-server-server60]
> net.VanillaDataServerSocket | Unexpected error for running server
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
> For additional commands, e-mail: users-help@felix.apache.org
>
>
--
Cheers,
Guillaume Nodet
------------------------
Blog: http://gnodet.blogspot.com/
------------------------
Open Source SOA
http://fusesource.com
Re: karaf not able to extract (and load) native libraries
Posted by "Richard S. Hall" <he...@ungoverned.org>.
On 1/18/11 13:27, Adam Crain wrote:
> Hi Irad,
>
> I am having a similar issue right now with Karaf 2.1.3.
>
> I have a bundle that wants to start using JNI in it's activator. I'm using
> the felix-maven-bnd plugin to add the following to my manifest:
>
> Bundle-NativeCode:
> lib/lucidx32/libdnp3java.so.0.9.3;osname=Linux;processor=x86
>
> The library is in the specified directory in the bundle jar, but karaf
> doesn't seem to be loading the library.
>
> Any ideas how to debug this?
If the bundle is self-contained (or you can make it self-contained) then
you can send it to me privately and I can see what is doing.
-> richard
> regards,
> Adam Crain
>
>
>
> On Tue, Jan 18, 2011 at 12:04 PM, Irad Dor<ir...@edgeci.com> wrote:
>
>> Hi,
>> We have a weird problem with native libraries. We've had Native code
>> working in the past, and for some reason it is not working anymore.
>>
>> 1. We have a bundle with native libraries (specified using maven
>> Bundle-NativeCode)
>> 2. The .so files appear in the jar file and also in the manifest
>> 3. The native libraries fail to load with the error below, and when I
>> check the cache - there are no native libraries present in the bundle
>> directory
>> 4. We use karaf 1.0.0a
>>
>> The error that we get is below. I also found it as an issue for karaf
>> 2.0.0 but this is not the version I'm using (see:
>> https://issues.apache.org/jira/browse/FELIX-1580?page=com.atlassian.jira
>> .plugin.system.issuetabpanels:all-tabpanel)
>>
>> Please help,
>> Thanks,
>> Irad.
>>
>>
>> java.lang.ArrayIndexOutOfBoundsException: 0
>> at
>> org.apache.felix.framework.util.manifestparser.R4Library.match(R4Library
>> .java:113)
>> at
>> org.apache.felix.framework.ModuleImpl$ModuleClassLoader.findLibrary(Modu
>> leImpl.java:1929)
>> at java.lang.ClassLoader.loadLibrary(ClassLoader.java:1705)
>> at java.lang.Runtime.loadLibrary0(Runtime.java:823)
>> at java.lang.System.loadLibrary(System.java:1028)
>> at
>> com.edgeci.lib.reutersanalyser.ReutersPacketAnalyzerInterface.<init>(Reu
>> tersPacketAnalyzerInterface.java:39)
>> at
>> com.edgeci.lib.reutersanalyser.ReutersAnalyser.__InitializePacketInterfa
>> ce(ReutersAnalyser.java:93)
>> at
>> com.edgeci.lib.reutersanalyser.ReutersAnalyser.InitializePacketInterface
>> (ReutersAnalyser.java)
>> at
>> com.edgeci.lib.reutersanalyser.ReutersAnalyser.__InitializePacketInterfa
>> ce(ReutersAnalyser.java:119)
>> at
>> com.edgeci.lib.reutersanalyser.ReutersAnalyser.InitializePacketInterface
>> (ReutersAnalyser.java)
>> at
>> com.edgeci.lib.reutersanalyser.ReutersAnalyser.__validate(ReutersAnalyse
>> r.java:127)
>> at
>> com.edgeci.lib.reutersanalyser.ReutersAnalyser.validate(ReutersAnalyser.
>> java)
>> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>> at
>> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.jav
>> a:39)
>> at
>> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessor
>> Impl.java:25)
>> at java.lang.reflect.Method.invoke(Method.java:597)
>> at org.apache.felix.ipojo.util.Callback.call(Callback.java:235)
>> at org.apache.felix.ipojo.util.Callback.call(Callback.java:191)
>> at
>> org.apache.felix.ipojo.handlers.lifecycle.callback.LifecycleCallback.cal
>> l(LifecycleCallback.java:86)
>> at
>> org.apache.felix.ipojo.handlers.lifecycle.callback.LifecycleCallbackHand
>> ler.__stateChanged(LifecycleCallbackHandler.java:162)
>> at
>> org.apache.felix.ipojo.handlers.lifecycle.callback.LifecycleCallbackHand
>> ler.stateChanged(LifecycleCallbackHandler.java)
>> at
>> org.apache.felix.ipojo.InstanceManager.setState(InstanceManager.java:441
>> )
>> at
>> org.apache.felix.ipojo.InstanceManager.start(InstanceManager.java:322)
>> at
>> org.apache.felix.ipojo.ComponentFactory.createInstance(ComponentFactory.
>> java:155)
>> at
>> org.apache.felix.ipojo.IPojoFactory.createComponentInstance(IPojoFactory
>> .java:301)
>> at
>> org.apache.felix.ipojo.IPojoFactory.createComponentInstance(IPojoFactory
>> .java:238)
>> at
>> org.apache.felix.ipojo.IPojoFactory.updated(IPojoFactory.java:625)
>> at
>> org.apache.felix.cm.impl.ConfigurationManager$ManagedServiceFactoryUpdat
>> e.run(ConfigurationManager.java:1279)
>> at
>> org.apache.felix.cm.impl.UpdateThread.run(UpdateThread.java:88)
>> 18 14:15:22.452 ERROR [essence-server-server60]
>> net.VanillaDataServerSocket | Unexpected error for running server
>>
>> ---------------------------------------------------------------------
>> 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: karaf not able to extract (and load) native libraries
Posted by Adam Crain <ac...@greenenergycorp.com>.
Hi Irad,
I am having a similar issue right now with Karaf 2.1.3.
I have a bundle that wants to start using JNI in it's activator. I'm using
the felix-maven-bnd plugin to add the following to my manifest:
Bundle-NativeCode:
lib/lucidx32/libdnp3java.so.0.9.3;osname=Linux;processor=x86
The library is in the specified directory in the bundle jar, but karaf
doesn't seem to be loading the library.
Any ideas how to debug this?
regards,
Adam Crain
On Tue, Jan 18, 2011 at 12:04 PM, Irad Dor <ir...@edgeci.com> wrote:
>
> Hi,
> We have a weird problem with native libraries. We've had Native code
> working in the past, and for some reason it is not working anymore.
>
> 1. We have a bundle with native libraries (specified using maven
> Bundle-NativeCode)
> 2. The .so files appear in the jar file and also in the manifest
> 3. The native libraries fail to load with the error below, and when I
> check the cache - there are no native libraries present in the bundle
> directory
> 4. We use karaf 1.0.0a
>
> The error that we get is below. I also found it as an issue for karaf
> 2.0.0 but this is not the version I'm using (see:
> https://issues.apache.org/jira/browse/FELIX-1580?page=com.atlassian.jira
> .plugin.system.issuetabpanels:all-tabpanel)
>
> Please help,
> Thanks,
> Irad.
>
>
> java.lang.ArrayIndexOutOfBoundsException: 0
> at
> org.apache.felix.framework.util.manifestparser.R4Library.match(R4Library
> .java:113)
> at
> org.apache.felix.framework.ModuleImpl$ModuleClassLoader.findLibrary(Modu
> leImpl.java:1929)
> at java.lang.ClassLoader.loadLibrary(ClassLoader.java:1705)
> at java.lang.Runtime.loadLibrary0(Runtime.java:823)
> at java.lang.System.loadLibrary(System.java:1028)
> at
> com.edgeci.lib.reutersanalyser.ReutersPacketAnalyzerInterface.<init>(Reu
> tersPacketAnalyzerInterface.java:39)
> at
> com.edgeci.lib.reutersanalyser.ReutersAnalyser.__InitializePacketInterfa
> ce(ReutersAnalyser.java:93)
> at
> com.edgeci.lib.reutersanalyser.ReutersAnalyser.InitializePacketInterface
> (ReutersAnalyser.java)
> at
> com.edgeci.lib.reutersanalyser.ReutersAnalyser.__InitializePacketInterfa
> ce(ReutersAnalyser.java:119)
> at
> com.edgeci.lib.reutersanalyser.ReutersAnalyser.InitializePacketInterface
> (ReutersAnalyser.java)
> at
> com.edgeci.lib.reutersanalyser.ReutersAnalyser.__validate(ReutersAnalyse
> r.java:127)
> at
> com.edgeci.lib.reutersanalyser.ReutersAnalyser.validate(ReutersAnalyser.
> java)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.jav
> a:39)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessor
> Impl.java:25)
> at java.lang.reflect.Method.invoke(Method.java:597)
> at org.apache.felix.ipojo.util.Callback.call(Callback.java:235)
> at org.apache.felix.ipojo.util.Callback.call(Callback.java:191)
> at
> org.apache.felix.ipojo.handlers.lifecycle.callback.LifecycleCallback.cal
> l(LifecycleCallback.java:86)
> at
> org.apache.felix.ipojo.handlers.lifecycle.callback.LifecycleCallbackHand
> ler.__stateChanged(LifecycleCallbackHandler.java:162)
> at
> org.apache.felix.ipojo.handlers.lifecycle.callback.LifecycleCallbackHand
> ler.stateChanged(LifecycleCallbackHandler.java)
> at
> org.apache.felix.ipojo.InstanceManager.setState(InstanceManager.java:441
> )
> at
> org.apache.felix.ipojo.InstanceManager.start(InstanceManager.java:322)
> at
> org.apache.felix.ipojo.ComponentFactory.createInstance(ComponentFactory.
> java:155)
> at
> org.apache.felix.ipojo.IPojoFactory.createComponentInstance(IPojoFactory
> .java:301)
> at
> org.apache.felix.ipojo.IPojoFactory.createComponentInstance(IPojoFactory
> .java:238)
> at
> org.apache.felix.ipojo.IPojoFactory.updated(IPojoFactory.java:625)
> at
> org.apache.felix.cm.impl.ConfigurationManager$ManagedServiceFactoryUpdat
> e.run(ConfigurationManager.java:1279)
> at
> org.apache.felix.cm.impl.UpdateThread.run(UpdateThread.java:88)
> 18 14:15:22.452 ERROR [essence-server-server60]
> net.VanillaDataServerSocket | Unexpected error for running server
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
> For additional commands, e-mail: users-help@felix.apache.org
>
>