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<[email protected]>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<[email protected]>  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:[email protected]]
Sent: 18 January 2011 17:08
To: [email protected]
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<[email protected]>  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: [email protected]
For additional commands, e-mail: [email protected]



--
Cheers,
Guillaume Nodet
------------------------
Blog: http://gnodet.blogspot.com/
------------------------
Open Source SOA
http://fusesource.com

---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]



---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]

Reply via email to