Is there a difference between extending ServiceTracker class and implementing ServiceTrackerCustomizer interface when tracking OSGi services?

0
votes

I am creating some OSGi bundles. They register services and also get (and of course use) each other's services.

I decided to use ServiceTracker instead of Declarative Services.

As I was searching for information about this I found two approach of tracking services.

The first one is creating an own tracker class for each service, which extends the ServiceTracker class and overrides the methods that need to be overridden. Then in the activator class creating a new instance of this tracker class giving the bundle context to it and open it for tracking.

The other approach is creating a tracker class for each service, which implements the ServiceTrackerCustomizer interface and overrides the methods that need to be overridden. Then in the activator class creating a new instance of the ServiceTracker class giving to it the bundle context, the name of the service that needs to be tracked and a new instance of our customizer class. Then open it for tracking.

Are there any differences between the two approaches? I would say no. In the ServiceTracker javadoc I can see that the ServiceTracker class also implements the ServiceTrackerCustomizer interface.

Could you please tell me the pros and cons on both the approaches? Thanks in advance.

2
javaosgimodularityosgi-bundle

2 Answers

1
votes

Here are my reasons:

Sub-class ServiceTracker if

  • You want to hard-code the constructor parameters of the super class. E.g.: Hardcode the type or filter. In this case it would not look nice if all of the users should know what filter the tracker should be instantiated with
  • You want to override (wrap) open, close or other functions of ServiceTracker
  • You want to extend the functionality of ServiceTracker. E.g.: By having an implementation that pre-filters service objects based on Java Generics equality

Implement the interface if:

  • You expect to switch to other ServiceTracker implementation in the future. ServiceTracker is an add-on for OSGi core, it is only part of the core spec since 5.0.0. Other, more effective implementations can be created in the future
  • You do not want to decide which constructors you want to override as the parameters are flexible from the view point of your business logic. Probably there will be more constructors of the standard ServiceTracker class in the future. If you sub-class it, your class will not support those constructors
  • You want to sub-class from another class in the implementation of ServiceTrackerCustomizer

Do not use ServiceTracker directly if

  • Declarative Services or other Component Model helps you writing cleaner and more stable code
1
votes

In over 12 years of developing with OSGi I don't think I have ever written a single ServiceTrackerCustomizer. IMHO it's just more convenient to directly subclass ServiceTracker and leave the customizer parameter null.

One simple reason it's easier to subclass is that you don't need to provide an implementation of the modifiedService method, which is rarely needed.

Functionally, however, the result will be the same so it's very much a personal preference.