[jira] [Comment Edited] (FELIX-4029) Improve use of BundleContext.getServiceReferences() API in ServiceTracker

["Herko ter Horst (JIRA)" <ji...@apache.org>]

    [ 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