felix-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Herko ter Horst (JIRA)" <j...@apache.org>
Subject [jira] [Comment Edited] (FELIX-4029) Improve use of BundleContext.getServiceReferences() API in ServiceTracker
Date Mon, 22 Apr 2013 19:49:18 GMT

    [ 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

Mime
View raw message