Well `ServiceTracker` needs a `BundleContext` as well and needs to be opened and closed as well. So we need to hook into the OSGi lifecycle. The simplest way to do this is to use a bundle activator. So even if we used `ServiceTracker` we would still need to have an activator and access the `ServiceTracker` from a "static context" inside `org.jboss.logging.LoggerProviders`. I assume using `FrameworkUtil` is out of the question.

Second since `ExtendedLogService` is a service provided by the Equinox OSGi framework there will be only one (per bundle) and it will never be reloaded. Using `ServiceTracker` would only make the code much more complicated without gaining anything. The `ServiceTracker` would have to be passed to `EquinoxLogger`. `EquinoxLogger` now can no longer operate on a single `org.eclipse.equinox.log.Logger` because then we would have to dynamically add and invalidate loggers when log services are added and removed. So `EquinoxLogger` needs to operate on an array of `org.eclipse.equinox.log.Logger`s instead of a single one. This means that things like `#isEnabled` would now have to iterate over an array of them and have to check each one. Also `EquinoxLogger` can't directly reference the logger array since it's contents may change so it needs to access them every time through `ServiceTracker`. Again there will only be a single `ExtendedLogService` so all this complexity doesn't buy us anything.