为了支持某些服务实现而不是其他服务,我编写了一个可定制的版本
java.util.ServiceLoader(通过优先级文件为非OSGi代码添加优先级和启用/禁用标志).

客户很高兴并希望为OSGi服务实现进行相同的定制.
设计的解决方案基于BundleContext上的getServiceReferences(Class<S> clazz, String filter)调用,并使用空过滤器来检索所有实现.

尽管如此,在如此低的水平上摆弄OSGi仍然带来了不好的品味.有很多样板代码(例如BundleActivator的强制子类型),使用的方法也会妨碍顺利升级到声明性服务和某些时间点.

我还阅读了有关SERVICE_RANKING属性的内容,但与上述方法中的首选项文件相比,它的缺点是每个实现都设置了自己的排名属性,之后无法更改排名.

所以我的问题是：对这种低级方法有什么好的论据？为什么要使用声明性服务呢？

最佳答案 OSGi的核心是动态环境.捆绑和服务可以随时进出(理论上).因此,应对这种环境的唯一方法是对等待发生变化的变化作出反应.

例如,一旦声明服务组件出现所有强制服务,它就会出现,如果一个消失,它将会消失.
基于服务加载程序或类似程序的解决方案将主动获取可用的服务(如果此类服务是必需的),那么您必须阻止它直到可用.这很容易导致应用程序死锁.

当然,在实践中,应用程序通常不那么动态.在大多数情况下,这只会影响应用程序的启动.因此,在许多情况下,阻塞行为可以起作用,但它会产生本质上脆弱的应用程序.

另一方面,如果您遇到应用程序需要在OSGi内部和外部运行的问题,则DS存在问题,因为它依赖于OSGi存在.
典型的例子是Aapache CXF和Apache Camel.两者都没有使用DS,而是在OSGi中发明了不同的抽象用法,因此OSGi中有时会出现问题.仍然很难改进这一点,因为他们也需要在OSGi之外工作.