felix-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Richard S. Hall" <he...@ungoverned.org>
Subject Re: OSGi R6 Native Code Namespace Aliases
Date Fri, 12 Dec 2014 20:37:05 GMT
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
>>>
>>>
>>
>


Mime
View raw message