[
https://issues.apache.org/jira/browse/FELIX-4029?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13638370#comment-13638370
]
Herko ter Horst edited comment on FELIX-4029 at 4/22/13 7:48 PM:
-----------------------------------------------------------------
There's no problem according to the specs. And no, as far I've been able to
determine, Equinox doesn't provide an implementation that takes advantage of
this.
However, given that the BundleContext API makes the class name a first class
citizen in its get[All]ServiceReference[s](...) methods, it seems reasonable to
assume that implementations treat it as such. Equinox, Knopflerfish and
Concierge all do it (by using the class name as key in a map, while filters are
matched "later"), Felix does not. So in fact the current implementation almost
seems to depend on the Felix framework implementation, which transforms the
class name into a filter.
The dm ServiceTracker implementation has 3 constructors: one that takes a
ServiceReference, one that takes a class name, and one that takes a filter. The
service reference is used as-is, the filter is used as-is, but the class name
is transformed into a filter (BTW, in my opinion there should be a fourth
constructor that takes a class name AND a filter).
BTW, the "root cause" seems to be the discrepancy between
BundleContext.addServiceListener(ServiceListener, String filter) and
BundleContext.getServiceReferences(String clazz, String filter).
was (Author: herko_ter_horst):
There's no problem according to the specs. And no, as far I've been able to
determine, Equinox doesn't provide an implementation that takes advantage of
this.
However, given that the BundleContext API makes the class name a first class
citizen in its get[All]ServiceReference[s](...) methods, it seems reasonable to
assume that implementations treat it as such. Equinox, Knopflerfish and
Concierge all do it (by using the class name as key in a map, while filters are
matched "later"), Felix does not. So in fact the current implementation almost
seems to depend on the Felix framework implementation, which transforms the
class name into a filter.
The dm ServiceTracker implementation has 3 constructors: one that takes a
ServiceReference, one that takes a class name, and one that takes a filter. The
service reference is used as-is, the filter is used as-is, but the class name
is transformed into a filter (BTW, in my opinion there should be a fourth
constructor that takes a class name AND a filter).
BTW, the "root cause" seems to be the discrepancy between
BundleContext.addServiceListener(ServiceListener, String [i]filter[/i]) and
BundleContext.getServiceReferences(String clazz, String [i]filter[/i]).
> Improve use of BundleContext.getServiceReferences() API in ServiceTracker
> -------------------------------------------------------------------------
>
> Key: FELIX-4029
> URL: https://issues.apache.org/jira/browse/FELIX-4029
> Project: Felix
> Issue Type: Improvement
> Components: Dependency Manager
> Affects Versions: dependencymanager-3.1.0
> Reporter: Herko ter Horst
> Labels: performance
>
> The org.apache.felix.dm.tracker.ServiceTracker implementation currently does
> not take full advantage of the BundleContext.getServiceReferences() API when
> retrieving initial service references on "open".
> The getServiceReferences() method accepts a class name and a filter. The
> ServiceTracker accepts either one (but not both). However, it transforms the
> class name into a filter and calls getServiceReferences() with only the
> filter.
> This prevents BundleContext implementations from taking advantage of the
> class name parameter. At least one implementation (Equinox) indexes service
> references by their service interface. The fact that the class name is not
> available leads to reduced performance in this case.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
