Mailing-List: contact dev-help@felix.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@felix.apache.org
Received-SPF: pass (nike.apache.org: domain of heavy@ungoverned.org designates
 209.85.213.180 as permitted sender)
Message-ID: <548EE024.2050003@ungoverned.org>
Date: Mon, 15 Dec 2014 08:20:36 -0500
From: "Richard S. Hall" <heavy@ungoverned.org>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10;
 rv:31.0) Gecko/20100101 Thunderbird/31.2.0
MIME-Version: 1.0
To: dev@felix.apache.org
Subject: Re: Native Selection Filters matching in Native Namespace
References: <548E628D.7020205@apache.org>
In-Reply-To: <548E628D.7020205@apache.org>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 7bit

On 12/14/14 23:24 , Bob Paulin wrote:
> Per the R6 Spec selection filters should be able to match launching 
> properties (p 75).  This works fine within the matching the is 
> currently happening within R4LibraryClause.match() method. However 
> since we're now deriving a Require-Capability (p 73 - 74) the matching 
> actually occurs again within the CapabilitySet.match() method against 
> the derived filter.
>
> For example.  On a Windows system with a x86_64 processor with a run 
> property of
> org.osgi.test.cases.framework.div.tb16="xyz"
>
> The following filter should pass:
>
> (&(osgi.native.osname~=win32)(osgi.native.processor~=x86_64)(org.osgi.test.cases.framework.div.tb16=xyz)) 
>
>
> The issue is within the CapabilitySet class we only match against 
> attributes within the osgi.native namespace so the launching 
> properties are not included so it fails to match the native code 
> requirement.

Sorry, but I guess I am confused. There is really no such thing as 
"within the osgi.native" namespace. Capabilities/Requirements have a 
namespace, which must match before matching of filters/attributes 
occurs. The attributes that can occur within a namespace is open ended. 
Perhaps that is all you meant.

If we have a generated capability and a generated requirement, I'd 
expect both to have the osgi.native namespace. Is this not the case? As 
far as launching properties, if they are intended to be part of the 
capability, shouldn't they just be added to the generated native 
capability and then everything would be fine, no?

-> richard

> So I'm curious what we should do here.  A few things come to mind:
>
> 1) Add the launch properties to the native namespace
> 2) Remove the selection-filter prior to passing it along to the 
> CapabilitySet
> 3) Generate the native capacity set but blacklist it from matching 
> (since we've already done it within the R4LibraryClause.match())
>
> Let me know if you have comments or other suggested approaches. I'm 
> thinking #3 may be best since additional matching to resolve the 
> bundle might not be needed but I might be missing something. Thanks!
>
> - Bob