felix-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Bob Paulin <...@bobpaulin.com>
Subject Re: OSGi R6 Native Code Namespace Aliases
Date Fri, 12 Dec 2014 20:27:08 GMT
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
>>>
>>>
>>
>
>


Mime
View raw message