On 12/14/14 23:24 , Bob Paulin wrote:
Per the R6 Spec selection filters should be able to match launching
properties (p 75). This works fine within the matching the is
currently happening within R4LibraryClause.match() method. However
since we're now deriving a Require-Capability (p 73 - 74) the matching
actually occurs again within the CapabilitySet.match() method against
the derived filter.
For example. On a Windows system with a x86_64 processor with a run
property of
org.osgi.test.cases.framework.div.tb16="xyz"
The following filter should pass:
(&(osgi.native.osname~=win32)(osgi.native.processor~=x86_64)(org.osgi.test.cases.framework.div.tb16=xyz))
The issue is within the CapabilitySet class we only match against
attributes within the osgi.native namespace so the launching
properties are not included so it fails to match the native code
requirement.
Sorry, but I guess I am confused. There is really no such thing as
"within the osgi.native" namespace. Capabilities/Requirements have a
namespace, which must match before matching of filters/attributes
occurs. The attributes that can occur within a namespace is open ended.
Perhaps that is all you meant.
If we have a generated capability and a generated requirement, I'd
expect both to have the osgi.native namespace. Is this not the case? As
far as launching properties, if they are intended to be part of the
capability, shouldn't they just be added to the generated native
capability and then everything would be fine, no?
-> richard
So I'm curious what we should do here. A few things come to mind:
1) Add the launch properties to the native namespace
2) Remove the selection-filter prior to passing it along to the
CapabilitySet
3) Generate the native capacity set but blacklist it from matching
(since we've already done it within the R4LibraryClause.match())
Let me know if you have comments or other suggested approaches. I'm
thinking #3 may be best since additional matching to resolve the
bundle might not be needed but I might be missing something. Thanks!
- Bob
