[
https://issues.apache.org/jira/browse/FELIX-1754?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12765383#action_12765383
]
Matthew Sykes commented on FELIX-1754:
--------------------------------------
Based on your updates I added the isAssignableTo checks and the issue came
back. As usual, things aren't as simple as I'd hoped.
I threw a couple of debug statements into
ServiceRegistrationImpl.isAssignableTo and isClassAccessible. When the
isAssignableTo check is run against the ServiceReference for the interface
associated with the reference, the requester and provider references are null
so the code falls into case 1.
RequesterWire = null
ProviderWire = null
Case 1
The interface class gets loaded successfully and then
ServiceRegistrationImpl.isClassAccessible is driven:
requestClass from requesterModule.getClassByDelegation = interface
foo.bar.event.EventEngine
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
isClassAccessible: targetClass= null
isClassAccessible: sourceClass == targetClass = false
serviceRef [foo.bar.event.EventEngine, org.osgi.service.event.EventAdmin] was
not assignable to foo.bar.event.EventEngine
If I'm reading the code correctly, it looks like the SCR bundle's class loader
is being used to resolve the the service interface. This only seems to happen
in "case 1" where no wire was found. Well, go figure, the manifest for the
bundle that's declared the reference is poorly constructed and relies on a
DynamicImport-Package: *.
So, it looks like a combination of dynamic import, the implementation of
isAssignableTo, and the use of a "smart" service factory is causing the
reference to remain unsatisfied. I don't know if this is just how things are
or if the framework should attempt to wire the package (because of the dynamic
import) or what...
At this point I'm not sure what's going on in Equinox as the external symptom
was the same; I'll have to look more closely tomorrow. Whatever that issue is,
it's most likely unrelated.
> 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.
