Hi,
according to the R4.2 OSGi specification https://osgi.org/download/r4v42/r4.core.pdf chapter 3.9.1 a bundle containing native code can use the "selection-filter" directive in the Bundle-NativeCode header to let the resolver select different native libraries based not only on osgi framework properties but also on system properties:
The below example from the specification shows that two libraries are declared for linux on x86, and that one or the other is selected based on the fact that a custom system property is set to a given value (gtk or qt).
Bundle-NativeCode:
nativecodewin32.dll;delta.dll;osname=win32;processor=x86;language=en,
nativecodegtk.so;osname=linux;processor=x86;language=en;selection-filter="(com.acme.windowing=gtk)",
nativecodeqt.so;osname=linux;processor=x86;language=en;selection-filter="(com.acme.windowing=qt)"
I was trying a similar configuration in Virgo 3.6.4 and this does not work, the Quasi Resolver framework always complains because the native library on linux cannot be resolved since the selection filter does not match:
A bundle could not be resolved because no match was found for the native code specification. Resolver error data <lib/jep.dll; processor=x86_64; osname=Win32, lib/libjep.dylib; processor=x86_64; osname=MacOSX, lib/python33/libjep.so; processor=x86_64; osname=Linux; selection-filter="(python=33)">. Caused by missing constraint in bundle <jep_3.4.1.201604121252>
constraint: <lib/jep.dll; processor=x86_64; osname=Win32, lib/libjep.dylib; processor=x86_64; osname=MacOSX, lib/python33/libjep.so; processor=x86_64; osname=Linux; selection-filter="(python=33)">
I am sure the problem is due to the selection-filter because replacing it with a negation will make it work.
I had a look at the sources and debugged Virgo 3.6.4 (Equinox 3.
up to class NativeCodeSpecificationImpl. The Equinox behaviour is to use the selection-filter and verify whether it checks against some properties as visible in line 66 of NativeCodeSpecificationImpl [1]
The probem is that the properties include only the following:
osgi.os=
org.osgi.framework.os.name=
org.osgi.framework.os.version=
osgi.ws=
org.osgi.framework.language=
org.osgi.framework.executionenvironment=
org.osgi.framework.system.packages=
org.osgi.framework.processor=
osgi.arch=
osgi.nl=
while no system property is included. Is this a problem in Equinox 3.8 or related to Virgo's use of Equinox 3.8?
I think it's strange that filters are tested against a map of properties that is called "platform properties", see [2].
GianMaria.
[1] http://git.eclipse.org/c/equinox/rt.equinox.framework.git/tree/bundles/org.eclipse.osgi/resolver/src/org/eclipse/osgi/internal/resolver/NativeCodeSpecificationImpl.java?h=R3_8_2#n66
[2] http://git.eclipse.org/c/equinox/rt.equinox.framework.git/tree/bundles/org.eclipse.osgi/resolver/src/org/eclipse/osgi/internal/resolver/NativeCodeSpecificationImpl.java?h=R3_8_2#n59
] 
Search
Help
Register
Login
Home
