You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@felix.apache.org by Bob Paulin <bo...@apache.org> on 2014/12/15 05:24:45 UTC
Native Selection Filters matching in Native Namespace
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. 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
Re: Native Selection Filters matching in Native Namespace
Posted by "Richard S. Hall" <he...@ungoverned.org>.
On 12/15/14 08:44 , Bob Paulin wrote:
> Responses inline.
> On 12/15/2014 7:20 AM, Richard S. Hall wrote:
>> 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.
> Let me clarify that the attributes that I am putting in the
> Provide-Capability are only those defined in the spec (p. 170).
Well, I don't think you should interpret that as a closed set, but even
if you do, then almost by definition it must include the launch
properties, since the spec says they must be matchable.
-> richard
> To your point I could add the launch attributes to the native
> namespace as you mentioned since it is after all just a map. This is
> approach 1 below.
>>
>> 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?
> Yes that should work.
>>
>> -> 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
>>
>>
>
Re: Native Selection Filters matching in Native Namespace
Posted by Bob Paulin <bo...@bobpaulin.com>.
Responses inline.
On 12/15/2014 7:20 AM, Richard S. Hall wrote:
> 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.
Let me clarify that the attributes that I am putting in the
Provide-Capability are only those defined in the spec (p. 170). To your
point I could add the launch attributes to the native namespace as you
mentioned since it is after all just a map. This is approach 1 below.
>
> 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?
Yes that should work.
>
> -> 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
>
>
Re: Native Selection Filters matching in Native Namespace
Posted by "Richard S. Hall" <he...@ungoverned.org>.
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