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
