何时使用ServiceLoader而不是像OSGi这样的东西 [英] When to use ServiceLoader over something like OSGi

问题描述

作为对依赖性过敏的人，我什么时候会使用像OSGi这样的内容而不是内置的java 6 http://java.sun.com/javase/6/docs/api/java/util/ServiceLoader.html （我想让插件罐子成为掉在）。

Being someone who is allergic to dependencies, when would I use something like OSGi instead of the built in java 6 http://java.sun.com/javase/6/docs/api/java/util/ServiceLoader.html (I want to let plugin jars just be dropped in).

（仅供参考，这是在scala应用程序中，对任何建议开放，ServiceLoader非常接近我想要的）。

(FYI this is in a scala app, open to any suggestions, ServiceLoader is pretty damn close to what I want).

推荐答案

如果 ServiceLoader 主要满足您的需求，那就说您正在通过文件的存在来寻找服务发现在班级路径上。这只是OSGi提供的一小部分。

If ServiceLoader mostly fits your needs, that says that you're looking for service discovery via the presence of files on the class path. That's only a small part of what OSGi provides.

OSGi将允许您在应用程序运行时动态安装捆绑包，宣传服务，撤销广告和卸载捆绑包。此外，作为服务的消费者，您可以热切地查找它们 - 使用过滤谓词查询 - 并检测提供的服务提供商何时来去。这些束不必位于类路径上，它们可以以各种形式提供; Jar记录和爆炸目录是我记得的两个。

OSGi will let you dynamically install bundles, advertise services, revoke advertisements, and uninstall bundles all while the application is running. Furthermore, as a consumer of services, you can look them up eagerly -- with filtering predicate queries -- and detect when offered service providers come and go. These bundles need not lie on the class path, and they can be provided in various forms; Jar files and "exploded directories" are the two I recall.

相比之下， ServiceLoader 只做一件事：它暴露了可发现的工厂。通常，您将创建一个工厂样式的接口，该接口使用一些参数来确定该提供程序是否可以提供适当的服务，例如将给定的字符集名称映射到 CharsetDecoder 。没有用于从这样的提供者获取和发布服务的正式协议。 OSGi确实正式确定了消费者与服务的绑定和解除绑定。当新的提供者上线时，消费者可以接收通知，并且当消费者获取和释放服务实例时，提供者可以接收通知。如果这个生命周期控制对您的服务很重要并且您放弃了OSGi，那么您必须自己构建它; ServiceLoader 不会那么远。

By contrast, ServiceLoader does just one thing: it exposes discoverable factories. Usually you'll create a factory-style interface that takes some argument to decide whether that provider can offer the appropriate service, such as mapping a given character set name to a CharsetDecoder. There's no formalized protocol for acquiring and releasing a service from such a provider. OSGi does formalize the binding and unbinding of consumers to services. The consumer can receive notification when new providers come online, and the provider can receive notification when a consumer acquires and releases a service instance. If this life-cycle control is important to your service and you forgo OSGi, you'll have to build this yourself; ServiceLoader doesn't go that far.

或者，您可以采取一种方法，而不是急切的服务查找和使用。更加被动的，声明性的方法，让其中一个OSGi依赖管理器将您所陈述的需求与可用的服务提供商相匹配。有许多依赖管理器可供选择。 Spring动态模块 是最强大的功能之一。

Alternately, rather than eager service lookup and use, you can take a more passive, declarative approach and let one of the OSGi dependency managers match your stated needs to the available service providers. There are many dependency managers to choose from. Spring Dynamic Modules is one of the most capable.

OSGi提供了许多其他中间件设施。我不会试图在这里推销你，因为你的问题主要集中在你错过了什么，选择 ServiceLoader 。

OSGi provides many other "middleware" facilities. I won't try to sell you on them here, as your question focuses mostly on what you'd be missing out on by choosing ServiceLoader.

这篇关于何时使用ServiceLoader而不是像OSGi这样的东西的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！