How to use OSGi fragments to contribute platform-dependent native code with the same filename?

Question

I am using the JNotify project to listen to file system events. This depends on one native library per OS:processor architecture. For example, there's one library for Windows x86, one library for x86-64 etc.

Monolithic bundle

Originally, I had one bundle that contained both the JNotify Java classes and the native code. The native code were declared in Bundle-NativeCode as follows:

(I've formatted these in the bnd style for better readibility... obviously the actual MANIFEST.MF files are properly formed).

Bundle-NativeCode: jnotify_64bit.dll;osname=Win32;osname="Windows NT (unknown)";osname = WindowsXP;osname = Windows2000;osname = Windows2003;osname = WindowsVista;osname = Windows7;osname = WindowsServer2008;osname= Windows8;osname = WindowsServer2012;processor = x86-64,\
 jnotify.dll;osname=Win32;osname="Windows NT (unknown)";osname = WindowsXP;osname = Windows2000;osname = Windows2003;osname = WindowsVista;osname = Windows7;osname = WindowsServer2008;osname = Windows8;osname = WindowsServer2012;processor = x86,\
 libjnotify.so;osname = Linux;processor = x86,\
 libjnotify64.so;osname = Linux;processor = x86-64,\
 libjnotify.dylib;osname = Mac OSX;processor = x86;processor = x86-64,\
 *

This worked well.

Move to fragments

I figured it would be 'nice' if I moved the libraries into separate fragment bundles so that I could just contribute the fragments for the architecture I am interested in. Taking the example of Linux, I split them into two bundles:

Linux 32 bit

Include-Resource: lib/libjnotify.so
Bundle-NativeCode: libjnotify.so;osname = Linux;processor = x86,\
    *
Fragment-Host: net.contentobjects.jnotify
Bundle-Version: 0.94.0

Linux 64 bit

Include-Resource: lib/libjnotify.so
Bundle-NativeCode: libjnotify.so;osname = Linux;processor = x86-64,\
    *
Fragment-Host: net.contentobjects.jnotify
Bundle-Version: 0.94.0

Note that these bundles are built from different source. Although the libjnotify.so filename is the same they are different files in different Eclipse projects. They have to be the same to work with JNotify.

Note that the same filename is contributed to the host bundle. In this case the filename is libjnotify.so.

If I run these on my 64 bit machine with the 64 bit bundle being loaded before the 32 bit one, it works.

However, if the 32 bit bundle gets loaded first, I get:

Couldn't initialise JNotify: java.lang.UnsatisfiedLinkError: /blah/generated/fw/bundle46/version0.0/net.contentobjects.jnotify.linux.x86-0.94.0.jar-lib/0/libjnotify.so: /blah/generated/fw/bundle46/version0.0/net.contentobjects.jnotify.linux.x86-0.94.0.jar-lib/0/libjnotify.so: wrong ELF class: ELFCLASS32 (Possible cause: architecture word width mismatch) (JnotifyFileSystemObserver.java:53, thread platformExecutor)

Clearly the 32 bit library is being loaded. But why? My Bundle-NativeCode defines the host must be a 32 bit Linux machine to use the 32 bit bundle's version. I thought if that clause doesn't match, the library is ignored?

Stuff I've tried

• Removing the optional wildcard... this just means the bundles don't resolve

Astarte

I assume Java 7's Watch Service is not an option. docs.oracle.com/javase/tutorial/essential/io/notification.html – Nippur

One day! I'll move to that when I can, but there's more testing and, as I understand it, Apple's JVM that needs to be updated first. – Astarte

I have used the native API in OSGi with one version and multiple versions without OSGi but not multiple versions in OSGi ;) – Nippur

Answer 1

Since your fragment occupy the same resource namespace only one .so file can be accessed. You can deploy only one fragment, or you could try putting them in different directories:

 Fragment 32-bit:
 Include-Resource: x32/libjnotify.so=lib/libjnotify.so

 Fragment 64-bit:
 Include-Resource: x64/libjnotify.so=lib/libjnotify.so

I also think you need to put the Bundle-NativeCode header in the host bundle and refer to the proper directories since I am I think this header is not merged in the host.

Constitute

Ok, thanks for the confirmation this is the issue. Is there any way to deploy both bundles but only have one fragment actually contribute their file? Could it be done at the OBR level, e.g. adding some kind of requirement to the repository.xml file to only deploy a given fragment in certain OSs? – Astarte

Great, this appears to work. I used the bnd assignment approach on Include-Resource to assign the libs into different folders. Bundle-NativeCode seems to be merged into the host just fine... This is Felix btw. Pointing Bundle-NativeCode at the new location still works, I guess because System.loadLibrary or whatever is used only cares about the 'base name' of the library and not the full path nor extension. – Astarte

Answer 2

Check what version of Eclipse/OSGi container are you running. I suspect you find that the container you are launching has os set to a 32 bit system.

Monro

"os.arch=amd64" => No, it's definitely 64 bit. I am also seeing the opposite behaviour on 32 bit, where if the 64 bit package gets loaded first I also get an UnsatisfiedLinkError. The container is Felix. – Astarte

Answer 3

If you don't mind being restricted to Equinox you can use one-fragment-per-platform solution with Eclipse-PlatformFilter. In this case, only one fragment with native code can be resolved and installed at any time thus avoiding namespace conflict.

Avowed