具有相同接口实现的不同 osgi 捆绑包 - 将该接口放在哪里？答案

【问题标题】：Different osgi bundles with implementations of the same interface - where to place that interface?具有相同接口实现的不同 osgi 捆绑包 - 将该接口放在哪里？
【发布时间】：2010-12-28 17:20:27
【问题描述】：

我目前正在一个新应用程序上测试 osgi (Spring DM)。应用程序需要能够监听文件系统事件。今天我用一个简单的基于时间的轮询器解决了这个问题，但是当 Java 7 发布时，我可能想用基于 NIO2 的实现来替换它。

到目前为止，我正在查看三个捆绑包，两个用于文件服务实现，一个用于使用其中一项服务的业务逻辑。这两个实现应该实现相同的接口，所以我的问题是，在哪里放置该接口？将接口放在包含实现的包中会导致服务依赖于它的消费者之一。

什么是最好的和最像 osgi 的方式来构建它？到目前为止，我最好的选择是创建一个新的“api”包，定义实现的通用接口。

【问题讨论】：

我认为你的“api模块”想法是要走的路。

标签： osgi

【解决方案1】：

单独的 api-bundle 可能是最好的选择。它允许您稍后替换捆绑实施。此外，使用单独的 api-bundle，您可以热替换当前的捆绑包，而无需消费者重新启动。

类（和接口）通过它们的名称和类加载器来识别。因此，如果您将服务接口与实现放在同一个包中，您将失去热替换正在运行的包的能力。即使接口具有相同的名称，并且在任何意义上都是相同的，但新部署的捆绑包具有不同的类加载器 => 消费者将新部署的捆绑包接口视为新类，并且不再满足其依赖关系。

有关服务兼容性和版本的更多信息（参见 cmets）：http://wiki.osgi.org/wiki/Service_Compatibility

【讨论】：

此外，您应该使用捆绑版本。这样，您甚至可以在一个框架中部署同一个 API 包的不同版本，甚至同一个服务。
虽然您可以使用 OSGi 做到这一点，但如果您有相同 API 的不同版本，这会将您的应用程序分成使用每个版本的区域，并且它们可能无法很好地合作，因为将有不兼容的类加载器。例如，默认情况下，OSGi 不会使实现不同版本 API 的服务可见。
没错。我只是想指出，在这里使用版本控制实际上很重要，例如，只有一个包（实现或 API）被更新。否则，您可能会陷入混乱，因为您看不到 API、实现包和使用包不匹配。你能解释一下“不兼容的类加载器”是什么意思吗？