OSGi R6 Native Code Namespace Aliases

[Bob Paulin <bo...@apache.org>]

Currently working on getting the OSGi R6 tests related to Native Code.  
The tests failures that I'm working through start with the name 
testNativeCode.  The tests are failing on a 
org.osgi.framework.Filter.matches() call between a raw map of Native 
Attributes such as Procssor, OS name, etc and the Native Namespace 
Filter Directive.  The raw map of attributes is as follows:

{org.osgi.test.cases.framework.div.tb16=xyz, 
org.osgi.test.cases.framework.div.tb15=abc, osgi.native.osversion=1.0.0, 
osgi.native.language=en, osgi.native.osname=Mac OS X, 
org.osgi.test.cases.framework.div.tb12=abc, osgi.native.processor=PPC}

I'm generating a filter which includes the following statement to make 
it pass (I've truncated for brevity):
(&(osgi.native.osname~=mac os x)(osgi.native.processor~=powerpc)

"ppc" is an alias for "powerpc" as defined in Table 4.2 (page 100) of 
the OSGi R6 specification.  Per section 8.7 (page 170)  we should create 
a list of osgi.native.processor attributes under the osgi.native 
namespace within the Provide-Capability to include these aliases.  Since 
the test is asserting the requirements are met by calling 
org.osgi.framework.Filter.matches() method on a raw map of attributes 
(no aliases) we would have to add all the aliases in the Filter.matches 
method to ensure the tests would pass.

Any thoughts on how this should be handled?  It seems like the test is 
encouraging an implementation that is not optimal for the framework.  I 
think deriving the aliases would be best handled once at startup rather 
than each time org.osgi.framework.Filter.matches is called.  Should the 
test be changed or am I missing an implementation option that would 
solve both concerns?

- Bob

Re: OSGi R6 Native Code Namespace Aliases

["Richard S. Hall" <he...@ungoverned.org>]

On 12/12/14 15:27 , Bob Paulin wrote:
> There is code within Felix that "normalizes" PPC to powerpc within the 
> R4LibraryClause class.  Perhaps the normalization is no longer needed?

It wouldn't be needed if you put all of the aliases into the constructed 
native capability.

-> richard

>
> - Bob
> On 12/12/2014 2:15 PM, Richard S. Hall wrote:
>> On 12/12/14 15:00 , Bob Paulin wrote:
>>> Hi Richard,
>>>
>>> Here's an approximation of what the CT code is doing:
>>>
>>> //First we get the native requirement for filters
>>> String filterDirective = "(&(osgi.native.osname~=mac os 
>>> x)(osgi.native.processor~=powerpc) )"
>>>
>>> //Create filter object
>>>      Filter filter = getContext().createFilter(filterDirective);
>>>
>>> //Mock what the framework would be providing
>>> Map macPPC = new HashMap();
>>>     macPPC.put("osgi.native.osname", "Mac OS X");
>>>     macPPC.put("osgi.native.processor", "PPC");
>>>         assertTrue("filter does not match map: " + filter + 
>>> ".matches(" + macPPC+ ")", filter.matches(macPPC));
>>>
>>> The above fails since the CT test would not go through any logic to 
>>> add aliases to the macPPC object.  Does this help or are you looking 
>>> for something else?
>>
>> Yeah, that helps and I agree that seems odd.
>>
>> It doesn't really seem like a valid test to me, since the filter 
>> shouldn't necessarily know anything about the native namespace aliases.
>>
>> I'll check around.
>>
>> -> richard
>>
>>>
>>> - Bob
>>> On 12/12/2014 1:32 PM, Richard S. Hall wrote:
>>>> On 12/12/14 13:44 , Bob Paulin wrote:
>>>>> Currently working on getting the OSGi R6 tests related to Native 
>>>>> Code.  The tests failures that I'm working through start with the 
>>>>> name testNativeCode.  The tests are failing on a 
>>>>> org.osgi.framework.Filter.matches() call between a raw map of 
>>>>> Native Attributes such as Procssor, OS name, etc and the Native 
>>>>> Namespace Filter Directive.  The raw map of attributes is as follows:
>>>>>
>>>>> {org.osgi.test.cases.framework.div.tb16=xyz, 
>>>>> org.osgi.test.cases.framework.div.tb15=abc, 
>>>>> osgi.native.osversion=1.0.0, osgi.native.language=en, 
>>>>> osgi.native.osname=Mac OS X, 
>>>>> org.osgi.test.cases.framework.div.tb12=abc, 
>>>>> osgi.native.processor=PPC}
>>>>>
>>>>> I'm generating a filter which includes the following statement to 
>>>>> make it pass (I've truncated for brevity):
>>>>> (&(osgi.native.osname~=mac os x)(osgi.native.processor~=powerpc)
>>>>>
>>>>> "ppc" is an alias for "powerpc" as defined in Table 4.2 (page 100) 
>>>>> of the OSGi R6 specification.  Per section 8.7 (page 170) we 
>>>>> should create a list of osgi.native.processor attributes under the 
>>>>> osgi.native namespace within the Provide-Capability to include 
>>>>> these aliases.  Since the test is asserting the requirements are 
>>>>> met by calling org.osgi.framework.Filter.matches() method on a raw 
>>>>> map of attributes (no aliases) we would have to add all the 
>>>>> aliases in the Filter.matches method to ensure the tests would pass.
>>>>>
>>>>> Any thoughts on how this should be handled?  It seems like the 
>>>>> test is encouraging an implementation that is not optimal for the 
>>>>> framework.  I think deriving the aliases would be best handled 
>>>>> once at startup rather than each time 
>>>>> org.osgi.framework.Filter.matches is called.  Should the test be 
>>>>> changed or am I missing an implementation option that would solve 
>>>>> both concerns?
>>>>
>>>> Not sure I completely understand. It is not clear to me what is 
>>>> being invoked on what from where. Can you show me some pseudo-code 
>>>> or something?
>>>>
>>>> -> richard
>>>>
>>>>>
>>>>> - Bob
>>>>
>>>>
>>>
>>
>>
>

Re: OSGi R6 Native Code Namespace Aliases

[Bob Paulin <bo...@bobpaulin.com>]

There is code within Felix that "normalizes" PPC to powerpc within the 
R4LibraryClause class.  Perhaps the normalization is no longer needed?

- Bob
On 12/12/2014 2:15 PM, Richard S. Hall wrote:
> On 12/12/14 15:00 , Bob Paulin wrote:
>> Hi Richard,
>>
>> Here's an approximation of what the CT code is doing:
>>
>> //First we get the native requirement for filters
>> String filterDirective = "(&(osgi.native.osname~=mac os 
>> x)(osgi.native.processor~=powerpc) )"
>>
>> //Create filter object
>>      Filter filter = getContext().createFilter(filterDirective);
>>
>> //Mock what the framework would be providing
>> Map macPPC = new HashMap();
>>     macPPC.put("osgi.native.osname", "Mac OS X");
>>     macPPC.put("osgi.native.processor", "PPC");
>>         assertTrue("filter does not match map: " + filter + 
>> ".matches(" + macPPC+ ")", filter.matches(macPPC));
>>
>> The above fails since the CT test would not go through any logic to 
>> add aliases to the macPPC object.  Does this help or are you looking 
>> for something else?
>
> Yeah, that helps and I agree that seems odd.
>
> It doesn't really seem like a valid test to me, since the filter 
> shouldn't necessarily know anything about the native namespace aliases.
>
> I'll check around.
>
> -> richard
>
>>
>> - Bob
>> On 12/12/2014 1:32 PM, Richard S. Hall wrote:
>>> On 12/12/14 13:44 , Bob Paulin wrote:
>>>> Currently working on getting the OSGi R6 tests related to Native 
>>>> Code.  The tests failures that I'm working through start with the 
>>>> name testNativeCode.  The tests are failing on a 
>>>> org.osgi.framework.Filter.matches() call between a raw map of 
>>>> Native Attributes such as Procssor, OS name, etc and the Native 
>>>> Namespace Filter Directive.  The raw map of attributes is as follows:
>>>>
>>>> {org.osgi.test.cases.framework.div.tb16=xyz, 
>>>> org.osgi.test.cases.framework.div.tb15=abc, 
>>>> osgi.native.osversion=1.0.0, osgi.native.language=en, 
>>>> osgi.native.osname=Mac OS X, 
>>>> org.osgi.test.cases.framework.div.tb12=abc, osgi.native.processor=PPC}
>>>>
>>>> I'm generating a filter which includes the following statement to 
>>>> make it pass (I've truncated for brevity):
>>>> (&(osgi.native.osname~=mac os x)(osgi.native.processor~=powerpc)
>>>>
>>>> "ppc" is an alias for "powerpc" as defined in Table 4.2 (page 100) 
>>>> of the OSGi R6 specification.  Per section 8.7 (page 170) we should 
>>>> create a list of osgi.native.processor attributes under the 
>>>> osgi.native namespace within the Provide-Capability to include 
>>>> these aliases.  Since the test is asserting the requirements are 
>>>> met by calling org.osgi.framework.Filter.matches() method on a raw 
>>>> map of attributes (no aliases) we would have to add all the aliases 
>>>> in the Filter.matches method to ensure the tests would pass.
>>>>
>>>> Any thoughts on how this should be handled?  It seems like the test 
>>>> is encouraging an implementation that is not optimal for the 
>>>> framework.  I think deriving the aliases would be best handled once 
>>>> at startup rather than each time org.osgi.framework.Filter.matches 
>>>> is called.  Should the test be changed or am I missing an 
>>>> implementation option that would solve both concerns?
>>>
>>> Not sure I completely understand. It is not clear to me what is 
>>> being invoked on what from where. Can you show me some pseudo-code 
>>> or something?
>>>
>>> -> richard
>>>
>>>>
>>>> - Bob
>>>
>>>
>>
>
>

Re: OSGi R6 Native Code Namespace Aliases

["Richard S. Hall" <he...@ungoverned.org>]

On 12/12/14 15:00 , Bob Paulin wrote:
> Hi Richard,
>
> Here's an approximation of what the CT code is doing:
>
> //First we get the native requirement for filters
> String filterDirective = "(&(osgi.native.osname~=mac os 
> x)(osgi.native.processor~=powerpc) )"
>
> //Create filter object
>      Filter filter = getContext().createFilter(filterDirective);
>
> //Mock what the framework would be providing
> Map macPPC = new HashMap();
>     macPPC.put("osgi.native.osname", "Mac OS X");
>     macPPC.put("osgi.native.processor", "PPC");
>         assertTrue("filter does not match map: " + filter + 
> ".matches(" + macPPC+ ")", filter.matches(macPPC));
>
> The above fails since the CT test would not go through any logic to 
> add aliases to the macPPC object.  Does this help or are you looking 
> for something else?

Yeah, that helps and I agree that seems odd.

It doesn't really seem like a valid test to me, since the filter 
shouldn't necessarily know anything about the native namespace aliases.

I'll check around.

-> richard

>
> - Bob
> On 12/12/2014 1:32 PM, Richard S. Hall wrote:
>> On 12/12/14 13:44 , Bob Paulin wrote:
>>> Currently working on getting the OSGi R6 tests related to Native 
>>> Code.  The tests failures that I'm working through start with the 
>>> name testNativeCode.  The tests are failing on a 
>>> org.osgi.framework.Filter.matches() call between a raw map of Native 
>>> Attributes such as Procssor, OS name, etc and the Native Namespace 
>>> Filter Directive.  The raw map of attributes is as follows:
>>>
>>> {org.osgi.test.cases.framework.div.tb16=xyz, 
>>> org.osgi.test.cases.framework.div.tb15=abc, 
>>> osgi.native.osversion=1.0.0, osgi.native.language=en, 
>>> osgi.native.osname=Mac OS X, 
>>> org.osgi.test.cases.framework.div.tb12=abc, osgi.native.processor=PPC}
>>>
>>> I'm generating a filter which includes the following statement to 
>>> make it pass (I've truncated for brevity):
>>> (&(osgi.native.osname~=mac os x)(osgi.native.processor~=powerpc)
>>>
>>> "ppc" is an alias for "powerpc" as defined in Table 4.2 (page 100) 
>>> of the OSGi R6 specification.  Per section 8.7 (page 170) we should 
>>> create a list of osgi.native.processor attributes under the 
>>> osgi.native namespace within the Provide-Capability to include these 
>>> aliases.  Since the test is asserting the requirements are met by 
>>> calling org.osgi.framework.Filter.matches() method on a raw map of 
>>> attributes (no aliases) we would have to add all the aliases in the 
>>> Filter.matches method to ensure the tests would pass.
>>>
>>> Any thoughts on how this should be handled?  It seems like the test 
>>> is encouraging an implementation that is not optimal for the 
>>> framework.  I think deriving the aliases would be best handled once 
>>> at startup rather than each time org.osgi.framework.Filter.matches 
>>> is called.  Should the test be changed or am I missing an 
>>> implementation option that would solve both concerns?
>>
>> Not sure I completely understand. It is not clear to me what is being 
>> invoked on what from where. Can you show me some pseudo-code or 
>> something?
>>
>> -> richard
>>
>>>
>>> - Bob
>>
>>
>

Re: OSGi R6 Native Code Namespace Aliases

[Bob Paulin <bo...@bobpaulin.com>]

Ok so sounds like I should remove the normalization and replace it with 
the aliases within the framework.  This should cause the test to pass 
since all the CT tests appear to just as you've said test the filter ~= 
operator.

So as far as next steps is there a way to provide feedback on the 
tests?  I'm a bit new to this.

- Bob
On 12/12/2014 2:37 PM, Richard S. Hall wrote:
> On 12/12/14 15:27 , Richard S. Hall wrote:
>> On 12/12/14 15:00 , Bob Paulin wrote:
>>> Hi Richard,
>>>
>>> Here's an approximation of what the CT code is doing:
>>>
>>> //First we get the native requirement for filters
>>> String filterDirective = "(&(osgi.native.osname~=mac os 
>>> x)(osgi.native.processor~=powerpc) )"
>>>
>>> //Create filter object
>>>      Filter filter = getContext().createFilter(filterDirective);
>>>
>>> //Mock what the framework would be providing
>>> Map macPPC = new HashMap();
>>>     macPPC.put("osgi.native.osname", "Mac OS X");
>>>     macPPC.put("osgi.native.processor", "PPC");
>>>         assertTrue("filter does not match map: " + filter + 
>>> ".matches(" + macPPC+ ")", filter.matches(macPPC));
>>>
>>> The above fails since the CT test would not go through any logic to 
>>> add aliases to the macPPC object.  Does this help or are you looking 
>>> for something else?
>>
>> Perhaps I still don't understand where the macPPC comes from. If it 
>> comes from the framework's actually native capability, then I would 
>> think it would use an list type for the values of osname and 
>> processor than contained all known aliases.
>>
>> If, on the other hand, macPPC is being created directly in the CT, 
>> then I don't see how it would work.
>
> Thinking about this some more, the test is actually pretty stupid, 
> since it doesn't really test the framework at all. It really is 
> testing our "~=" filter operator. I think in this case they are 
> treating "~=" as ignoring case, which perhaps we don't do.
>
> -> richard
>
>>
>> -> richard
>>
>>>
>>> - Bob
>>> On 12/12/2014 1:32 PM, Richard S. Hall wrote:
>>>> On 12/12/14 13:44 , Bob Paulin wrote:
>>>>> Currently working on getting the OSGi R6 tests related to Native 
>>>>> Code.  The tests failures that I'm working through start with the 
>>>>> name testNativeCode.  The tests are failing on a 
>>>>> org.osgi.framework.Filter.matches() call between a raw map of 
>>>>> Native Attributes such as Procssor, OS name, etc and the Native 
>>>>> Namespace Filter Directive.  The raw map of attributes is as follows:
>>>>>
>>>>> {org.osgi.test.cases.framework.div.tb16=xyz, 
>>>>> org.osgi.test.cases.framework.div.tb15=abc, 
>>>>> osgi.native.osversion=1.0.0, osgi.native.language=en, 
>>>>> osgi.native.osname=Mac OS X, 
>>>>> org.osgi.test.cases.framework.div.tb12=abc, 
>>>>> osgi.native.processor=PPC}
>>>>>
>>>>> I'm generating a filter which includes the following statement to 
>>>>> make it pass (I've truncated for brevity):
>>>>> (&(osgi.native.osname~=mac os x)(osgi.native.processor~=powerpc)
>>>>>
>>>>> "ppc" is an alias for "powerpc" as defined in Table 4.2 (page 100) 
>>>>> of the OSGi R6 specification.  Per section 8.7 (page 170) we 
>>>>> should create a list of osgi.native.processor attributes under the 
>>>>> osgi.native namespace within the Provide-Capability to include 
>>>>> these aliases.  Since the test is asserting the requirements are 
>>>>> met by calling org.osgi.framework.Filter.matches() method on a raw 
>>>>> map of attributes (no aliases) we would have to add all the 
>>>>> aliases in the Filter.matches method to ensure the tests would pass.
>>>>>
>>>>> Any thoughts on how this should be handled?  It seems like the 
>>>>> test is encouraging an implementation that is not optimal for the 
>>>>> framework.  I think deriving the aliases would be best handled 
>>>>> once at startup rather than each time 
>>>>> org.osgi.framework.Filter.matches is called.  Should the test be 
>>>>> changed or am I missing an implementation option that would solve 
>>>>> both concerns?
>>>>
>>>> Not sure I completely understand. It is not clear to me what is 
>>>> being invoked on what from where. Can you show me some pseudo-code 
>>>> or something?
>>>>
>>>> -> richard
>>>>
>>>>>
>>>>> - Bob
>>>>
>>>>
>>>
>>
>
>

Re: OSGi R6 Native Code Namespace Aliases

["Richard S. Hall" <he...@ungoverned.org>]

On 12/12/14 15:27 , Richard S. Hall wrote:
> On 12/12/14 15:00 , Bob Paulin wrote:
>> Hi Richard,
>>
>> Here's an approximation of what the CT code is doing:
>>
>> //First we get the native requirement for filters
>> String filterDirective = "(&(osgi.native.osname~=mac os 
>> x)(osgi.native.processor~=powerpc) )"
>>
>> //Create filter object
>>      Filter filter = getContext().createFilter(filterDirective);
>>
>> //Mock what the framework would be providing
>> Map macPPC = new HashMap();
>>     macPPC.put("osgi.native.osname", "Mac OS X");
>>     macPPC.put("osgi.native.processor", "PPC");
>>         assertTrue("filter does not match map: " + filter + 
>> ".matches(" + macPPC+ ")", filter.matches(macPPC));
>>
>> The above fails since the CT test would not go through any logic to 
>> add aliases to the macPPC object.  Does this help or are you looking 
>> for something else?
>
> Perhaps I still don't understand where the macPPC comes from. If it 
> comes from the framework's actually native capability, then I would 
> think it would use an list type for the values of osname and processor 
> than contained all known aliases.
>
> If, on the other hand, macPPC is being created directly in the CT, 
> then I don't see how it would work.

Thinking about this some more, the test is actually pretty stupid, since 
it doesn't really test the framework at all. It really is testing our 
"~=" filter operator. I think in this case they are treating "~=" as 
ignoring case, which perhaps we don't do.

-> richard

>
> -> richard
>
>>
>> - Bob
>> On 12/12/2014 1:32 PM, Richard S. Hall wrote:
>>> On 12/12/14 13:44 , Bob Paulin wrote:
>>>> Currently working on getting the OSGi R6 tests related to Native 
>>>> Code.  The tests failures that I'm working through start with the 
>>>> name testNativeCode.  The tests are failing on a 
>>>> org.osgi.framework.Filter.matches() call between a raw map of 
>>>> Native Attributes such as Procssor, OS name, etc and the Native 
>>>> Namespace Filter Directive.  The raw map of attributes is as follows:
>>>>
>>>> {org.osgi.test.cases.framework.div.tb16=xyz, 
>>>> org.osgi.test.cases.framework.div.tb15=abc, 
>>>> osgi.native.osversion=1.0.0, osgi.native.language=en, 
>>>> osgi.native.osname=Mac OS X, 
>>>> org.osgi.test.cases.framework.div.tb12=abc, osgi.native.processor=PPC}
>>>>
>>>> I'm generating a filter which includes the following statement to 
>>>> make it pass (I've truncated for brevity):
>>>> (&(osgi.native.osname~=mac os x)(osgi.native.processor~=powerpc)
>>>>
>>>> "ppc" is an alias for "powerpc" as defined in Table 4.2 (page 100) 
>>>> of the OSGi R6 specification.  Per section 8.7 (page 170) we should 
>>>> create a list of osgi.native.processor attributes under the 
>>>> osgi.native namespace within the Provide-Capability to include 
>>>> these aliases.  Since the test is asserting the requirements are 
>>>> met by calling org.osgi.framework.Filter.matches() method on a raw 
>>>> map of attributes (no aliases) we would have to add all the aliases 
>>>> in the Filter.matches method to ensure the tests would pass.
>>>>
>>>> Any thoughts on how this should be handled?  It seems like the test 
>>>> is encouraging an implementation that is not optimal for the 
>>>> framework.  I think deriving the aliases would be best handled once 
>>>> at startup rather than each time org.osgi.framework.Filter.matches 
>>>> is called.  Should the test be changed or am I missing an 
>>>> implementation option that would solve both concerns?
>>>
>>> Not sure I completely understand. It is not clear to me what is 
>>> being invoked on what from where. Can you show me some pseudo-code 
>>> or something?
>>>
>>> -> richard
>>>
>>>>
>>>> - Bob
>>>
>>>
>>
>

Re: OSGi R6 Native Code Namespace Aliases

["Richard S. Hall" <he...@ungoverned.org>]

On 12/12/14 15:00 , Bob Paulin wrote:
> Hi Richard,
>
> Here's an approximation of what the CT code is doing:
>
> //First we get the native requirement for filters
> String filterDirective = "(&(osgi.native.osname~=mac os 
> x)(osgi.native.processor~=powerpc) )"
>
> //Create filter object
>      Filter filter = getContext().createFilter(filterDirective);
>
> //Mock what the framework would be providing
> Map macPPC = new HashMap();
>     macPPC.put("osgi.native.osname", "Mac OS X");
>     macPPC.put("osgi.native.processor", "PPC");
>         assertTrue("filter does not match map: " + filter + 
> ".matches(" + macPPC+ ")", filter.matches(macPPC));
>
> The above fails since the CT test would not go through any logic to 
> add aliases to the macPPC object.  Does this help or are you looking 
> for something else?

Perhaps I still don't understand where the macPPC comes from. If it 
comes from the framework's actually native capability, then I would 
think it would use an list type for the values of osname and processor 
than contained all known aliases.

If, on the other hand, macPPC is being created directly in the CT, then 
I don't see how it would work.

-> richard

>
> - Bob
> On 12/12/2014 1:32 PM, Richard S. Hall wrote:
>> On 12/12/14 13:44 , Bob Paulin wrote:
>>> Currently working on getting the OSGi R6 tests related to Native 
>>> Code.  The tests failures that I'm working through start with the 
>>> name testNativeCode.  The tests are failing on a 
>>> org.osgi.framework.Filter.matches() call between a raw map of Native 
>>> Attributes such as Procssor, OS name, etc and the Native Namespace 
>>> Filter Directive.  The raw map of attributes is as follows:
>>>
>>> {org.osgi.test.cases.framework.div.tb16=xyz, 
>>> org.osgi.test.cases.framework.div.tb15=abc, 
>>> osgi.native.osversion=1.0.0, osgi.native.language=en, 
>>> osgi.native.osname=Mac OS X, 
>>> org.osgi.test.cases.framework.div.tb12=abc, osgi.native.processor=PPC}
>>>
>>> I'm generating a filter which includes the following statement to 
>>> make it pass (I've truncated for brevity):
>>> (&(osgi.native.osname~=mac os x)(osgi.native.processor~=powerpc)
>>>
>>> "ppc" is an alias for "powerpc" as defined in Table 4.2 (page 100) 
>>> of the OSGi R6 specification.  Per section 8.7 (page 170) we should 
>>> create a list of osgi.native.processor attributes under the 
>>> osgi.native namespace within the Provide-Capability to include these 
>>> aliases.  Since the test is asserting the requirements are met by 
>>> calling org.osgi.framework.Filter.matches() method on a raw map of 
>>> attributes (no aliases) we would have to add all the aliases in the 
>>> Filter.matches method to ensure the tests would pass.
>>>
>>> Any thoughts on how this should be handled?  It seems like the test 
>>> is encouraging an implementation that is not optimal for the 
>>> framework.  I think deriving the aliases would be best handled once 
>>> at startup rather than each time org.osgi.framework.Filter.matches 
>>> is called.  Should the test be changed or am I missing an 
>>> implementation option that would solve both concerns?
>>
>> Not sure I completely understand. It is not clear to me what is being 
>> invoked on what from where. Can you show me some pseudo-code or 
>> something?
>>
>> -> richard
>>
>>>
>>> - Bob
>>
>>
>

Re: OSGi R6 Native Code Namespace Aliases

[Bob Paulin <bo...@bobpaulin.com>]

Hi Richard,

Here's an approximation of what the CT code is doing:

//First we get the native requirement for filters
String filterDirective = "(&(osgi.native.osname~=mac os 
x)(osgi.native.processor~=powerpc) )"

//Create filter object
      Filter filter = getContext().createFilter(filterDirective);

//Mock what the framework would be providing
Map macPPC = new HashMap();
     macPPC.put("osgi.native.osname", "Mac OS X");
     macPPC.put("osgi.native.processor", "PPC");
         assertTrue("filter does not match map: " + filter + ".matches(" 
+ macPPC+ ")", filter.matches(macPPC));

The above fails since the CT test would not go through any logic to add 
aliases to the macPPC object.  Does this help or are you looking for 
something else?

- Bob
On 12/12/2014 1:32 PM, Richard S. Hall wrote:
> On 12/12/14 13:44 , Bob Paulin wrote:
>> Currently working on getting the OSGi R6 tests related to Native 
>> Code.  The tests failures that I'm working through start with the 
>> name testNativeCode.  The tests are failing on a 
>> org.osgi.framework.Filter.matches() call between a raw map of Native 
>> Attributes such as Procssor, OS name, etc and the Native Namespace 
>> Filter Directive.  The raw map of attributes is as follows:
>>
>> {org.osgi.test.cases.framework.div.tb16=xyz, 
>> org.osgi.test.cases.framework.div.tb15=abc, 
>> osgi.native.osversion=1.0.0, osgi.native.language=en, 
>> osgi.native.osname=Mac OS X, 
>> org.osgi.test.cases.framework.div.tb12=abc, osgi.native.processor=PPC}
>>
>> I'm generating a filter which includes the following statement to 
>> make it pass (I've truncated for brevity):
>> (&(osgi.native.osname~=mac os x)(osgi.native.processor~=powerpc)
>>
>> "ppc" is an alias for "powerpc" as defined in Table 4.2 (page 100) of 
>> the OSGi R6 specification.  Per section 8.7 (page 170) we should 
>> create a list of osgi.native.processor attributes under the 
>> osgi.native namespace within the Provide-Capability to include these 
>> aliases.  Since the test is asserting the requirements are met by 
>> calling org.osgi.framework.Filter.matches() method on a raw map of 
>> attributes (no aliases) we would have to add all the aliases in the 
>> Filter.matches method to ensure the tests would pass.
>>
>> Any thoughts on how this should be handled?  It seems like the test 
>> is encouraging an implementation that is not optimal for the 
>> framework.  I think deriving the aliases would be best handled once 
>> at startup rather than each time org.osgi.framework.Filter.matches is 
>> called.  Should the test be changed or am I missing an implementation 
>> option that would solve both concerns?
>
> Not sure I completely understand. It is not clear to me what is being 
> invoked on what from where. Can you show me some pseudo-code or 
> something?
>
> -> richard
>
>>
>> - Bob
>
>

Re: OSGi R6 Native Code Namespace Aliases

["Richard S. Hall" <he...@ungoverned.org>]

On 12/12/14 13:44 , Bob Paulin wrote:
> Currently working on getting the OSGi R6 tests related to Native 
> Code.  The tests failures that I'm working through start with the name 
> testNativeCode.  The tests are failing on a 
> org.osgi.framework.Filter.matches() call between a raw map of Native 
> Attributes such as Procssor, OS name, etc and the Native Namespace 
> Filter Directive.  The raw map of attributes is as follows:
>
> {org.osgi.test.cases.framework.div.tb16=xyz, 
> org.osgi.test.cases.framework.div.tb15=abc, 
> osgi.native.osversion=1.0.0, osgi.native.language=en, 
> osgi.native.osname=Mac OS X, 
> org.osgi.test.cases.framework.div.tb12=abc, osgi.native.processor=PPC}
>
> I'm generating a filter which includes the following statement to make 
> it pass (I've truncated for brevity):
> (&(osgi.native.osname~=mac os x)(osgi.native.processor~=powerpc)
>
> "ppc" is an alias for "powerpc" as defined in Table 4.2 (page 100) of 
> the OSGi R6 specification.  Per section 8.7 (page 170)  we should 
> create a list of osgi.native.processor attributes under the 
> osgi.native namespace within the Provide-Capability to include these 
> aliases.  Since the test is asserting the requirements are met by 
> calling org.osgi.framework.Filter.matches() method on a raw map of 
> attributes (no aliases) we would have to add all the aliases in the 
> Filter.matches method to ensure the tests would pass.
>
> Any thoughts on how this should be handled?  It seems like the test is 
> encouraging an implementation that is not optimal for the framework.  
> I think deriving the aliases would be best handled once at startup 
> rather than each time org.osgi.framework.Filter.matches is called.  
> Should the test be changed or am I missing an implementation option 
> that would solve both concerns?

Not sure I completely understand. It is not clear to me what is being 
invoked on what from where. Can you show me some pseudo-code or something?

-> richard

>
> - Bob