felix-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Richard S. Hall" <he...@ungoverned.org>
Subject Re: karaf not able to extract (and load) native libraries
Date Tue, 18 Jan 2011 18:57:20 GMT
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<acrain@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<irad.dor@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<irad.dor@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


Mime
View raw message