One more thing to notice which we ran into: When an OSGi Bundle calls into native code, this works flawlessly, even if the native library is not part of the bundle. However, when you have native code calling into the Java land (in our case for hardware triggered events), this will fail, because the callback inside the OSGi bundle cannot be found, as it was not loaded by the system classloader.
We worked around this by putting the native library in the LD_LIBRARY_PATH
and the accompanying hardware SDK jars in the lib\ext folder of the VM. Not
the nicest way, but the only one we could get to work.
Mit freundlichen Grüßen / Best regards
i.A. Daniel Schneller
IT Software Engineer
Java Development / Basis³ Development
(Embedded image moved to file: pic23816.gif)GfD
GfD Gesellschaft für Datenverarbeitung mbH
Industriestr.10
D-42929 Wermelskirchen
Deutschland / Germany
phone: +49-2196-76-2887
fax: +49-2196-76-2782
e-mail: [email protected]
Besuchen Sie uns auch im Internet unter www.gfd.de
Amtsgericht Köln HR B 36326
USt-IdNr.: DE 811 254 705
Geschäftsführer:
Oliver Tackmann, Matthias Böcker
|------------>
| Von: |
|------------>
>--------------------------------------------------------------------------------------------------------------------------------------------------|
|[email protected]
|
>--------------------------------------------------------------------------------------------------------------------------------------------------|
|------------>
| An: |
|------------>
>--------------------------------------------------------------------------------------------------------------------------------------------------|
|[email protected]
|
>--------------------------------------------------------------------------------------------------------------------------------------------------|
|------------>
| Datum: |
|------------>
>--------------------------------------------------------------------------------------------------------------------------------------------------|
|27.04.2010 12:13
|
>--------------------------------------------------------------------------------------------------------------------------------------------------|
|------------>
| Betreff: |
|------------>
>--------------------------------------------------------------------------------------------------------------------------------------------------|
|RE: [osgi-dev] loading native code outside of the bundle
|
>--------------------------------------------------------------------------------------------------------------------------------------------------|
|------------>
| Gesendet |
| von: |
|------------>
>--------------------------------------------------------------------------------------------------------------------------------------------------|
|[email protected]
|
>--------------------------------------------------------------------------------------------------------------------------------------------------|
Just to clarify: There are two options to deal with native code.
The one is the "OSGi way" of doing it, this is embedding the shared library
into the bundle and using Bundle-NativeCode to make the library available.
This is the preferred way since then the native code is under proper
lifecycle management and the Bundle-NativeCode is a very powerful facility
for supporting multiple platforms.
If this is not an option, then you have to fall back to the standard Java
way of dealing with native code, which is a scan through java.library.path
(which is by default LD_LIBRARY_PATH on *nix). Even though implementation
of OSGi frameworks typically override findLibrary in their bundle, the code
path taken by calling System.loadLibrary will call loadLibrary0 directly if
findLibrary previously returned null.
What could happen though is that your framework implements findLibrary in
such a way that it directly throws an UnsatisfiedLinkError, e.g., when you
try to load a library and you have no Bundle-NativeCode directive in your
manifest. In this case, you have an immediate failure and there is no fall
back. I can't see anything in the specs that prevent frameworks from doing
so. As a consequence, you would not be able to call System.loadLibrary from
within a bundle to load libraries outside of the bundle.
Cheers,
Jan.
------------------------------------------------------------
MSc Jan S. Rellermeyer
Systems Group, Department of Computer Science, ETH Zurich
CAB E 78, Universitaetstrasse 6, CH-8092 Zürich, Switzerland
http://www.systems.ethz.ch
------------------------------------------------------------
-----Original Message-----
From: [email protected] [mailto:[email protected]
] On Behalf Of Christopher Armstrong
Sent: Dienstag, 27. April 2010 04:32
To: OSGi Developer Mail List
Subject: Re: [osgi-dev] loading native code outside of the bundle
On 27/04/2010, at 11:47 AM, Ikuo Yamasaki wrote:
> BJ> Did you try this out?
>
> Yes and I succeeded in loading the code.
>
> However, from the OSGi Spec point of view,
> I cannot find whether it is proper way.
> (This might be not OSGi issue but System.loadLibrary issue.)
>
> That's why I asked.
As far as I can tell from reading the OSGi specification, there is no
other way, and this is the method I use in my own code. The OSGi
framework you're using should have installed a custom classloader that
will be used to locate the shared library using the Bundle-NativeCode
header, so all ought to be fine.
Cheers
Chris
--------
Christopher Armstrong
[email protected]
_______________________________________________
OSGi Developer Mail List
[email protected]
https://mail.osgi.org/mailman/listinfo/osgi-dev
_______________________________________________
OSGi Developer Mail List
[email protected]
https://mail.osgi.org/mailman/listinfo/osgi-dev
--
IMPORTANT NOTICE:
This email is confidential, may be legally privileged, and is for the
intended recipient only. Access, disclosure, copying, distribution, or
reliance on any of it by anyone else is prohibited and may be a criminal
offence. Please delete if obtained in error and email confirmation to the
sender.<<attachment: pic23816.gif>>
_______________________________________________ OSGi Developer Mail List [email protected] https://mail.osgi.org/mailman/listinfo/osgi-dev
