为了支持某些服务实现而不是其他服务，我编写了一个可自定义的java.util.ServiceLoader版本（通过优先级文件为非OSGi代码添加优先级和启用/禁用标志）。
客户很高兴并希望为OSGi服务实现进行相同的自定义。
设计的解决方案基于getServiceReferences(Class<S> clazz, String filter)上的BundleContext调用，并使用null过滤器来检索所有实现。
尽管如此，在如此低的水平上摆弄OSGi仍然带来了不好的品味。有很多样板代码（例如BundleActivator的强制子类型），使用的方法也会阻碍声明性服务的平滑升级和某些时间点。
我还阅读了SERVICE_RANKING属性，但与上述方法中的偏好文件相比，它的缺点是每个实现都设置了自己的排名属性，并且无法更改排名之后。
所以我的问题是：对这种低级方法有什么好的论据？为什么要使用声明性服务？
答案 0 :(得分：1)
核心OSGi是一个动态环境。捆绑和服务可以随时进出（理论上）。因此，应对这种环境的唯一方法是对等待事情发生的变化做出反应。
例如，一旦声明服务组件出现所有强制服务，它就会出现，如果一个消失，它将会消失。 基于服务加载程序或类似程序的解决方案将主动获取可用的服务（如果此类服务是必需的），那么您必须阻止它直到可用。这很容易导致应用程序死锁。
当然，在实践中，应用程序通常不那么动态。在大多数情况下，这只会影响应用程序的启动。因此，在许多情况下，阻塞行为可以起作用，但它会产生一个本质上很脆弱的应用程序。
另一方面，如果您遇到应用程序需要在OSGi内部和外部运行的问题，则DS存在问题，因为它依赖于OSGi存在。 典型的例子是Aapache CXF和Apache Camel。两者都没有使用DS，而是在OSGi中发明了不同的抽象用法，因此OSGi中有时会出现问题。仍然很难改进这一点，因为他们也需要在OSGi之外工作。