To support certain service implementations over others, I wrote a custom version java.util.ServiceLoader
(adds a priority flag and is enabled / disabled for implementations via preference files for code other than OSGi).
The client was satisfied and needed the same setup for OSGi service implementations. The developed solution is based on a call getServiceReferences(Class<S> clazz, String filter)
to BundleContext
and uses a filter null
to retrieve all implementations.
However, messing with OSGi at such a low level leaves a bad taste. There are many code templates (for example, mandatory subtypes BundleActivator
), and the approach used will also prevent the smooth updating of declarative services, and for some time.
I also read about the property SERVICE_RANKING
, but compared to the preference files from the above approach, it has a drawback that each implementation sets its own ranking property, and subsequently it is impossible to change the ranking.
So my question is: what are some good arguments against this low-level approach? Why should declarative services be used instead?
source
share