[
https://issues.apache.org/jira/browse/FELIX-1754?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12765518#action_12765518
]
Matthew Sykes commented on FELIX-1754:
--------------------------------------
Felix,
> 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.
The values associated with m_factory and m_svcObj are, in fact, instances of
DelayedComponentManager. The name of the component is
'foo.bar.event.internal.EventEngineImpl' - which happens to match the name of
the implementation class. The toString representation from
AbstractComponentManager is "Component: " + getName() + " (" + getId() + ")";
> 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
After spending the time with the code yesterday, I have to agree. I'm able to
get around this with a "proper" manifest that codes a direct import for the
package without relying on dynamic import. While that's the change I'm making
locally to get the desired behavior, it still seems like the
ServiceReference.isAssignableTo doesn't handle the dynamic import scenario that
involves and extender and a service factory.
Karl,
> Did you try with felix 2.0.1/trunk?
Yes. This behavior was observed with the code in the trunk.
Is it possible that an attempt to wire to the target package could be useful in
the case where the requester bundle doesn't have an existing wire and it does
have a matching dynamic import header? I have no idea how the resolver works
so I'm just throwing out as a question.
Thanks.
> 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.
