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:27:29 GMT
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

View raw message