[
https://issues.apache.org/jira/browse/FELIX-1754?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12765400#action_12765400
]
Felix Meschberger commented on FELIX-1754:
------------------------------------------
Well, actually, the resolution is -- unfortunately for you -- quite easy and
clearly described in the spec (Section 112.3 References to Services in the R4.2
Compendium Manual, DS 1.1):
The services that are selected by a reference are called the target
services.
These are the services selected by the
BundleContext.getServiceReferences
method where the first argument is the reference's interface and the
second
argument is the reference's target property, which must be a valid
filter.
So, the spec refers to the getServiceReferences method and using the
getAllServiceReferences method is therefore in my understanding violating the
spec.
>From the POV of the Felix DS implementation, I fear there is nothing to be
>done.
But... what worries me is your output:
> isClassAccessible: m_factory = Component:
foo.bar.event.internal.EventEngineImpl (11)
> isClassAccessible: m_svcObj = Component:
foo.bar.event.internal.EventEngineImpl (11)
> isClassAccessible: sourceClass= class
org.apache.felix.scr.impl.manager.DelayedComponentManager
If you are using SCR to register the service, then m_factory is probably the
DelayedComponentManager instance and not the EventEngineImpl instance ! I think
your log output is incorrect.
Anyway, the problem is that an SCR class -- the DelayedComponentManager acting
as the ServiceFactory -- is used to load the interface class, a situation which
is definitely wrong. And a situation, which I assumed Karl has fixed for
2.0.1....
The problem here is, that the m_factory may not be used to verify accessibility
since the service may be registered as a ServiceFactory on behalf of the real
bundle. So the actual provider bundle must probably be used to verify
accessibility and not the ServiceFactory object's class loader.
> 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.
