felix-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Thomas Watson (JIRA)" <j...@apache.org>
Subject [jira] [Updated] (FELIX-3934) osgi.identity capabilities from fragments can cause problems when resolving multiple fragments
Date Tue, 26 Feb 2013 15:00:20 GMT

     [ 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

Mime
View raw message