[
https://issues.apache.org/jira/browse/FELIX-1754?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12769259#action_12769259
]
Richard S. Hall commented on FELIX-1754:
----------------------------------------
I think perhaps the issue is in ServiceRegistrationImpl.isClassAccessible(). In
this method it tries to get the service type from the registered service object
and in the case of a service factory will use that instead of the service
object. Currently, if the factory is used to retrieve the service type and the
type is not found, it does a comparison to null which will always return false.
Maybe we need to do something like this instead:
private boolean isClassAccessible(Class clazz)
{
try
{
// Try to load from the service object or service factory class.
Class sourceClass = (m_factory != null)
? m_factory.getClass() : m_svcObj.getClass();
Class targetClass = Util.loadClassUsingClass(sourceClass,
clazz.getName());
return ((m_factory != null) && (targetClass == null)) ? true :
(targetClass == clazz);
}
catch (Exception ex)
{
// Ignore this and return false.
}
return false;
}
So if the factory doesn't have access, we always return true instead of always
returning false. We could potentially try to make a more fine-grained decision
by getting the bundle associated with the service factory class and return true
when the type if not found if the factory type comes from a bundle other than
the registering bundle. This assumes that extenders register services using the
context of the bundle they are extending and not their own.
Thoughts?
> 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: Framework
> Affects Versions: felix-2.2.0
> Reporter: Matthew Sykes
> Priority: Minor
> Attachments: assignable.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.
