作为一个对依赖项过敏的人，我什么时候会使用 OSGi 之类的东西来代替内置的 java 6http://java.sun.com/javase/6/docs/api/java/util/ServiceLoader.html http://java.sun.com/javase/6/docs/api/java/util/ServiceLoader.html（我想让插件罐子直接放进去）。
（仅供参考，这是一个 scala 应用程序，欢迎任何建议，ServiceLoader 非常接近我想要的）。
If ServiceLoader主要满足您的需求，这表明您正在通过类路径上存在的文件来寻找服务发现。这只是 OSGi 提供的一小部分。
OSGi 将允许您在应用程序运行时动态安装捆绑包、广告服务、撤销广告以及卸载捆绑包。此外，作为服务的消费者，您可以通过过滤谓词查询急切地查找它们，并检测所提供的服务提供商何时出现和消失。这些包不需要位于类路径上，并且可以以各种形式提供；我记得有两个 Jar 文件和“分解目录”。
相比之下，ServiceLoader只做一件事：它暴露可发现的工厂。通常，您将创建一个工厂式接口，该接口采用一些参数来决定该提供程序是否可以提供适当的服务，例如将给定的字符集名称映射到CharsetDecoder。没有用于从此类提供商处获取和发布服务的正式协议。 OSGi 确实规范了消费者与服务的绑定和解除绑定。当新的提供者上线时，消费者可以收到通知，当消费者获取和释放服务实例时，提供者也可以收到通知。如果这种生命周期控制对您的服务很重要并且您放弃了 OSGi，那么您必须自己构建它；ServiceLoader并没有走那么远。
或者，您可以采取更被动的声明性方法，而不是急切地查找和使用服务，让 OSGi 依赖项管理器之一将您声明的需求与可用的服务提供者相匹配。有许多依赖管理器可供选择。Spring动态模块 http://www.springsource.org/osgi是最有能力的人之一。
OSGi 提供了许多其他“中间件”设施。我不会在这里向您推销它们，因为您的问题主要集中在您会因为选择而错过什么ServiceLoader.
本文内容由网友自发贡献，版权归原作者所有，本站不承担相应法律责任。如您发现有涉嫌抄袭侵权的内容，请联系:hwhale#tublm.com(使用前将#替换为@)
