Return-Path: X-Original-To: apmail-felix-dev-archive@www.apache.org Delivered-To: apmail-felix-dev-archive@www.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id 57AB5D5EE for ; Tue, 26 Feb 2013 14:54:15 +0000 (UTC) Received: (qmail 90465 invoked by uid 500); 26 Feb 2013 14:54:14 -0000 Delivered-To: apmail-felix-dev-archive@felix.apache.org Received: (qmail 90402 invoked by uid 500); 26 Feb 2013 14:54:14 -0000 Mailing-List: contact dev-help@felix.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: dev@felix.apache.org Delivered-To: mailing list dev@felix.apache.org Received: (qmail 90343 invoked by uid 99); 26 Feb 2013 14:54:13 -0000 Received: from arcas.apache.org (HELO arcas.apache.org) (140.211.11.28) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 26 Feb 2013 14:54:13 +0000 Date: Tue, 26 Feb 2013 14:54:13 +0000 (UTC) From: "Thomas Watson (JIRA)" To: dev@felix.apache.org Message-ID: In-Reply-To: References: Subject: [jira] [Created] (FELIX-3934) osgi.identity capabilities from fragments can cause problems when resolving multiple fragments MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-JIRA-FingerPrint: 30527f35849b9dde25b450d4833f0394 Thomas Watson created FELIX-3934: ------------------------------------ Summary: osgi.identity capabilities from fragments can cause problems when resolving multiple fragments Key: FELIX-3934 URL: https://issues.apache.org/jira/browse/FELIX-3934 Project: Felix Issue Type: Bug Components: Resolver Environment: All Reporter: Thomas Watson If you are resolving multiple fragments against the same host at the same time then the osgi.identity capabilities provided by fragments can cause the wiring result to be miscalculated because a wrapped host is not used to populate the wires. Here is a simple scenario: Bundle-SymbolicName: A Bundle-SymbolicName: F1 Fragment-Host: A Bundle-SymbolicName: F2 Fragment-Host: A Bundle-SymbolicName: B Require-Capability: osgi.identity; filter:="(osgi.identity=F2)" During the final phase of resolution when calling populateWireMap, if the first Resource target is B then it will cause a recursive call to populateWireMap using the raw resouce of F2 since it provides the identity capability required by B. This ultimately will result in another recursive call to populateWireMap using the raw resource of A since it provides the host capability required by F2. This is wrong, we must ensure only wrappedResources for the host of a resolving fragment resource are passed to populateWireMap. All other namespaces besides osgi.identity are considered payload capabilities from fragments. This results in proper wrapping of the capabilities provided by fragments which then results in proper calls to populateWireMap since capabilities coming from fragments will be properly wrapped with their hosting resource. But in the case of osgi.identity no wrapping is done for the capability so we are left with the raw capability when resolving a required wire to the osgi.identity. I will provide a patch with a potential fix. The fix is probably not the most elegant approach. It basically spacial cases the osgi.identity namespace in the recursive call to populateWireMap to check if the providing resource is a fragment and if so then find the target wrapped host for proper calls to populateWireMap -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira