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
