[ 
https://issues.apache.org/jira/browse/FELIX-1754?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12765346#action_12765346
 ] 

Richard S. Hall commented on FELIX-1754:
----------------------------------------

To be clear, the framework doesn't require the requester have access to *all* 
class names with which the target service was registered, it requires that the 
ones to which it does have access are the same as the provider.

If no check for assignability is being done by SCR currently, then it would 
*have* to be done if introducing your patch. Perhaps you are not seeing an 
issue because you do not have incompatible service versions registered.

At any rate, if you are running from trunk and it is still exhibiting the 
issue, then I agree it needs to be looked into. I will wait for Felix to 
comment, since he is the expert here.

> Usage of BundleContext.getServiceReferences results in failure to activate 
> components
> -------------------------------------------------------------------------------------
>
>                 Key: FELIX-1754
>                 URL: https://issues.apache.org/jira/browse/FELIX-1754
>             Project: Felix
>          Issue Type: Bug
>          Components: Declarative Services (SCR)
>    Affects Versions: scr-1.2.0
>            Reporter: Matthew Sykes
>         Attachments: felix-1754.diff
>
>
> I'm attempting to move some code from Equinox to Felix that makes use of the 
> declarative services 1.1 runtime.  Many of the components in our bundles 
> declare multiple 'provide' elements in the service declaration .  In general 
> these services consist of a standardized interface in one package and 
> extensions to that interface in another.  Depending on the requirements of 
> the code using the component, other bundles will declare their components 
> with references to either the standardized interface or the extended 
> interface.
> The issue I'm seeing is that the Felix SCR fails to activate some components 
> because it's failing to resolve references to the service provided by another 
> component.  It turns out that the SCR is using 
> BundleContext.getServiceReferences instead of 
> BundleContext.getAllServiceReferences to locate candidate services when 
> resolving references.  Unfortunately, the getServiceReference flavor requires 
> that the using bundle have access to all class names under which the target 
> service was registered - not just the interface associated with the reference.
> Given the use-case I've described and the behavior of Equinox, I believe the 
> Felix SCR should be using BundleContext.getAllServiceReferences(..) to 
> resolve references and rely on the bundle creator to define the correct 
> imports.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

Reply via email to