Daniel, just for curiosity, I guess the call from native into Java only fails 
if the native library is not in a bundle but the callback is? 
Why are you not putting the library into the same bundle? The one does not seem 
to make a lot of sense without the other and that way your call should succeed 
since both the native code and the Java callback method are loaded through the 
same class loader. 

I did a lot of embedded systems software in the past so I frequently had to 
deal with native code and the OSGi way of handling it always seemed a lot 
cleaner and much more powerful to me. Simply having the possibility to build a 
single bundle that--despite native code--runs on multiple platform is a 
substantial benefit, both for development and later for deployment.

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 [email protected]
Sent: Mittwoch, 28. April 2010 13:54
To: [email protected]
Subject: RE: [osgi-dev] loading native code outside of the bundle



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.

_______________________________________________
OSGi Developer Mail List
[email protected]
https://mail.osgi.org/mailman/listinfo/osgi-dev

Reply via email to