You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@felix.apache.org by "Matthew Sykes (JIRA)" <ji...@apache.org> on 2009/10/13 23:37:31 UTC
[jira] Created: (FELIX-1754) Usage of
BundleContext.getServiceReferences results in failure to activate
components
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
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.
[jira] Updated: (FELIX-1754) Usage of
BundleContext.getServiceReferences results in failure to activate
components
Posted by "Matthew Sykes (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/FELIX-1754?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Matthew Sykes updated FELIX-1754:
---------------------------------
Attachment: felix-1754.diff
Simple patch to have the DependencyManager use getAllServiceReferences instead of getServiceReferences. This addressed the component activation problem.
> 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.
[jira] Updated: (FELIX-1754) Usage of
BundleContext.getServiceReferences results in failure to activate
components
Posted by "Matthew Sykes (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/FELIX-1754?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Matthew Sykes updated FELIX-1754:
---------------------------------
Component/s: (was: Declarative Services (SCR))
Framework
Priority: Minor (was: Major)
Affects Version/s: (was: scr-1.2.0)
felix-2.2.0
Changing component and severity. The workaround of using an explicit import package is simple and straightforward.
> 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: 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.
[jira] Closed: (FELIX-1754) Usage of
BundleContext.getServiceReferences results in failure to activate
components
Posted by "Richard S. Hall (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/FELIX-1754?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Richard S. Hall closed FELIX-1754.
----------------------------------
Resolution: Fixed
Assignee: Richard S. Hall
Thanks. Closing this as fixed. Please open a new bug report if additional issues are uncovered.
> 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.0.1
> Reporter: Matthew Sykes
> Assignee: Richard S. Hall
> Priority: Minor
> Fix For: felix-2.2.0
>
> Attachments: assignable.diff, FELIX-1754.txt
>
>
> 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.
[jira] Commented: (FELIX-1754) Usage of
BundleContext.getServiceReferences results in failure to activate
components
Posted by "Matthew Sykes (JIRA)" <ji...@apache.org>.
[ 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.
[jira] Commented: (FELIX-1754) Usage of
BundleContext.getServiceReferences results in failure to activate
components
Posted by "Richard S. Hall (JIRA)" <ji...@apache.org>.
[ 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.
[jira] Commented: (FELIX-1754) Usage of
BundleContext.getServiceReferences results in failure to activate
components
Posted by "Richard S. Hall (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/FELIX-1754?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12765273#action_12765273 ]
Richard S. Hall commented on FELIX-1754:
----------------------------------------
I am not so sure if that is accurate, since it depends on how SCR is implemented. If SCR uses the bundle context of the component bundles to register services and service listeners, then it should work fine using a normal service listener.
If SCR uses a single service listener for all components and registers it on its own context, then it would need to use an AllServiceListener as you suggest. However, it would also need to use ServiceReference.isAssignableTo() to filter them before injecting them into components to make sure they are actually compatible with the component being injected. Since your patch doesn't do this, I am a little suspicious that it is completely correct.
FYI, there was a bug in service filter that was fixed in the new Felix framework 2.0.1 that could be related, so you should test with 2.0.1 to see how that impacts your scenario. 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.
[jira] Commented: (FELIX-1754) Usage of
BundleContext.getServiceReferences results in failure to activate
components
Posted by "Matthew Sykes (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/FELIX-1754?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12770316#action_12770316 ]
Matthew Sykes commented on FELIX-1754:
--------------------------------------
Richard, I'll apply to trunk and give it a shot tomorrow. Will update with the results. 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: Framework
> Affects Versions: felix-2.0.1
> Reporter: Matthew Sykes
> Priority: Minor
> Fix For: felix-2.2.0
>
> Attachments: assignable.diff, FELIX-1754.txt
>
>
> 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.
[jira] Commented: (FELIX-1754) Usage of
BundleContext.getServiceReferences results in failure to activate
components
Posted by "Richard S. Hall (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/FELIX-1754?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12770333#action_12770333 ]
Richard S. Hall commented on FELIX-1754:
----------------------------------------
Thanks, I won't make any guarantees that it will work, but hopefully it does. Effectively, we are trying to approximate the wired state of a service object without actually having the service object (i.e., we only have a service factory), so to some degree it is like stabbing in the dark...
> 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.0.1
> Reporter: Matthew Sykes
> Priority: Minor
> Fix For: felix-2.2.0
>
> Attachments: assignable.diff, FELIX-1754.txt
>
>
> 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.
[jira] Commented: (FELIX-1754) Usage of
BundleContext.getServiceReferences results in failure to activate
components
Posted by "Felix Meschberger (JIRA)" <ji...@apache.org>.
[ 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.
[jira] Updated: (FELIX-1754) Usage of
BundleContext.getServiceReferences results in failure to activate
components
Posted by "Richard S. Hall (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/FELIX-1754?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Richard S. Hall updated FELIX-1754:
-----------------------------------
Fix Version/s: (was: felix-2.2.0)
felix-2.0.2
> 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.0.1
> Reporter: Matthew Sykes
> Assignee: Richard S. Hall
> Priority: Minor
> Fix For: felix-2.0.2
>
> Attachments: assignable.diff, FELIX-1754.txt
>
>
> 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.
[jira] Commented: (FELIX-1754) Usage of
BundleContext.getServiceReferences results in failure to activate
components
Posted by "Karl Pauls (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/FELIX-1754?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12765457#action_12765457 ]
Karl Pauls commented on FELIX-1754:
-----------------------------------
It should be fixed in 2.0.1 for some cases. Unfortunately, we will not be able to avoid asking the factory in all cases. Did you try with felix 2.0.1/trunk?
> 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.
[jira] Commented: (FELIX-1754) Usage of
BundleContext.getServiceReferences results in failure to activate
components
Posted by "Richard S. Hall (JIRA)" <ji...@apache.org>.
[ 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.
[jira] Updated: (FELIX-1754) Usage of
BundleContext.getServiceReferences results in failure to activate
components
Posted by "Richard S. Hall (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/FELIX-1754?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Richard S. Hall updated FELIX-1754:
-----------------------------------
Affects Version/s: (was: felix-2.2.0)
felix-2.0.1
Fix Version/s: felix-2.2.0
> 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.0.1
> Reporter: Matthew Sykes
> Priority: Minor
> Fix For: felix-2.2.0
>
> 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.
[jira] Commented: (FELIX-1754) Usage of
BundleContext.getServiceReferences results in failure to activate
components
Posted by "Matthew Sykes (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/FELIX-1754?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12765328#action_12765328 ]
Matthew Sykes commented on FELIX-1754:
--------------------------------------
Thank your for your comments. The behavior I'm reporting was observed when using the current (as of mid-afternoon today) Felix SCR and Framework. The same behavior was also observed when using the Felix SCR with Equinox 3.5.
I'm not trying to suggest that the patch I sent was complete, only that the current behavior doesn't seem appropriate. Making the minor change from getServiceReferences to getAllServiceReferences resolved my issue by removing the arbitrary filtering done by the framework to ensure that the using bundle has access to *all* classes that the target service was registered with.
If you feel that adding a check to verify assignability is appropriate during reference resolution, that seems reasonable and correct - provided the check is made using the interface declared on the reference and not for *all* class names that the target service was registered with. This behavior is particularly important when using graphs of DS components as a component can only offer a single service declared with multiple object names.
> 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.
[jira] Updated: (FELIX-1754) Usage of
BundleContext.getServiceReferences results in failure to activate
components
Posted by "Matthew Sykes (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/FELIX-1754?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Matthew Sykes updated FELIX-1754:
---------------------------------
Attachment: (was: felix-1754.diff)
> 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.
[jira] Updated: (FELIX-1754) Usage of
BundleContext.getServiceReferences results in failure to activate
components
Posted by "Richard S. Hall (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/FELIX-1754?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Richard S. Hall updated FELIX-1754:
-----------------------------------
Attachment: FELIX-1754.txt
> 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.0.1
> Reporter: Matthew Sykes
> Priority: Minor
> Fix For: felix-2.2.0
>
> Attachments: assignable.diff, FELIX-1754.txt
>
>
> 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.
[jira] Commented: (FELIX-1754) Usage of
BundleContext.getServiceReferences results in failure to activate
components
Posted by "Matthew Sykes (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/FELIX-1754?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12765555#action_12765555 ]
Matthew Sykes commented on FELIX-1754:
--------------------------------------
As an experiment, I changed ServiceRegistrationImpl.isAssignableTo to attempt to get the requester's wire after the call to getClassByDelegation. While the wire was null before the attempt to load the class, the getClassByDelegation resolved the dynamic import and wired the requester to the provider.
While I don't expect this is necessarily the correct way to address the problem, it did seem to work.
> 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: 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.
[jira] Commented: (FELIX-1754) Usage of
BundleContext.getServiceReferences results in failure to activate
components
Posted by "Karl Pauls (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/FELIX-1754?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12765557#action_12765557 ]
Karl Pauls commented on FELIX-1754:
-----------------------------------
Interesting. We need to look into it. 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: 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.
[jira] Commented: (FELIX-1754) Usage of
BundleContext.getServiceReferences results in failure to activate
components
Posted by "Matthew Sykes (JIRA)" <ji...@apache.org>.
[ 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.
[jira] Issue Comment Edited: (FELIX-1754) Usage of
BundleContext.getServiceReferences results in failure to activate
components
Posted by "Richard S. Hall (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/FELIX-1754?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12765273#action_12765273 ]
Richard S. Hall edited comment on FELIX-1754 at 10/13/09 3:06 PM:
------------------------------------------------------------------
I am not so sure if that is accurate, since it depends on how SCR is implemented. If SCR uses the bundle context of the component bundles to register services and service listeners, then it should work fine using a normal service listener.
If SCR uses a single service listener for all components and registers it on its own context, then it would need to use an AllServiceListener as you suggest. However, it would also need to use ServiceReference.isAssignableTo() to filter them before injecting them into components to make sure they are actually compatible with the component being injected. Since your patch doesn't do this, I am a little suspicious that it is completely correct.
FYI, there was a bug in service filtering that was fixed in the new Felix framework 2.0.1 and that could be related, so you should test with 2.0.1 to see how that impacts your scenario. Thanks!
was (Author: rickhall):
I am not so sure if that is accurate, since it depends on how SCR is implemented. If SCR uses the bundle context of the component bundles to register services and service listeners, then it should work fine using a normal service listener.
If SCR uses a single service listener for all components and registers it on its own context, then it would need to use an AllServiceListener as you suggest. However, it would also need to use ServiceReference.isAssignableTo() to filter them before injecting them into components to make sure they are actually compatible with the component being injected. Since your patch doesn't do this, I am a little suspicious that it is completely correct.
FYI, there was a bug in service filter that was fixed in the new Felix framework 2.0.1 that could be related, so you should test with 2.0.1 to see how that impacts your scenario. 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.
[jira] Commented: (FELIX-1754) Usage of
BundleContext.getServiceReferences results in failure to activate
components
Posted by "Richard S. Hall (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/FELIX-1754?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12770235#action_12770235 ]
Richard S. Hall commented on FELIX-1754:
----------------------------------------
Matthew, I am not sure if you are still around, but I have attached a patch to try to address this issue. Is there anyway you could try it out? If you cannot easily apply the patch to trunk yourself, I could also send you a patch felix.jar. 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: Framework
> Affects Versions: felix-2.0.1
> Reporter: Matthew Sykes
> Priority: Minor
> Fix For: felix-2.2.0
>
> Attachments: assignable.diff, FELIX-1754.txt
>
>
> 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.
[jira] Updated: (FELIX-1754) Usage of
BundleContext.getServiceReferences results in failure to activate
components
Posted by "Matthew Sykes (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/FELIX-1754?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Matthew Sykes updated FELIX-1754:
---------------------------------
Attachment: assignable.diff
Re-acquire the wire after loading the class instance
> 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.
[jira] Commented: (FELIX-1754) Usage of
BundleContext.getServiceReferences results in failure to activate
components
Posted by "Matthew Sykes (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/FELIX-1754?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12772056#action_12772056 ]
Matthew Sykes commented on FELIX-1754:
--------------------------------------
I finally got a chance to test and it worked for me. Thanks again.
> 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.0.1
> Reporter: Matthew Sykes
> Priority: Minor
> Fix For: felix-2.2.0
>
> Attachments: assignable.diff, FELIX-1754.txt
>
>
> 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.