Mailing-List: contact dev-help@felix.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@felix.apache.org
Date: Tue, 26 Feb 2013 15:00:20 +0000 (UTC)
From: "Thomas Watson (JIRA)" <jira@apache.org>
To: dev@felix.apache.org
Message-ID: <JIRA.12634166.1361890367873.342449.1361890820327@arcas>
In-Reply-To: <JIRA.12634166.1361890367873@arcas>
References: <JIRA.12634166.1361890367873@arcas>
Subject: [jira] [Updated] (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


     [ https://issues.apache.org/jira/browse/FELIX-3934?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Thomas Watson updated FELIX-3934:
---------------------------------

    Attachment: org.apache.felix.resolver.patch

Here is the possible fix.  I also added the scenario to Main (scenario 7).  When things go wrong you will see that the wiring result does not provide any wires for fragment F1.  I could not find an easy way to force the situation.  You basically have to try and force resource B to be the first resource to call populateWireMap.  If any other resource is first then the proper wrapped resource of A is used to populate the wire map.
                
> 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
>         Attachments: org.apache.felix.resolver.patch
>
>
> 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