具有相同接口实现的不同 osgi 捆绑包 - 该接口放置在哪里？
我目前正在一个新应用程序上测试 osgi (Spring DM)。应用程序需要能够侦听文件系统事件。今天我用一个简单的基于时间的轮询器解决了这个问题，但是当 Java 7 发布时我可能想用基于 NIO2 的实现来替换它。
到目前为止，我正在研究三个捆绑包，两个用于文件服务实现，一个用于使用其中一项服务的业务逻辑。这两个实现应该实现相同的接口，所以我的问题是，该接口放置在哪里？将接口放置在包含实现的包中将导致服务依赖于其使用者之一。
最好的、最像 osgi 的构建方式是什么？到目前为止，我最好的选择是创建一个新的“api”包，定义实现的通用接口。
I'm currently testing out osgi (Spring DM) on a new application. The application needs to be able to listen to file system events. Today I've solved this with a simple time based poller, but when Java 7 is released I probably want to replace that with a NIO2 based implementation.
So far I'm looking at three bundles, two for the file service implementations and one for the business logic consuming one of the services. The two implementations should implement the same interface so my question is, where to place that interface? Placing the interface in the bundle containing the implementation would cause the service to depend on one of its consumers.
What would be the best and most osgi-like way to structure this? So far my best bet is to create a new "api" bundle defining the common interfaces for the implementations.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
单独的 api-bundle 可能是最好的选择。它允许您稍后替换捆绑包实现。此外，通过单独的 api-bundle，您可以热替换当前的包，而无需消费者重新启动。
类（和接口）通过其名称和类加载器来识别。因此，如果您将服务接口放置在与实现相同的包中，您将失去热替换正在运行的包的能力。尽管接口具有相同的名称，并且在每种意义上都是相同的，但新部署的包具有不同的类加载器 =>消费者将新部署的bundles接口视为一个新类，并且不再满足其依赖关系。
有关服务兼容性和版本的更多信息（请参阅评论）：http://wiki.osgi.org/wiki /服务_兼容性
Separete api-bundle is probably the best choise. It allows you to replace bundle implentation later. Also with separate api-bundle you are able to hot-replace your current bundle with out the need for consumer to restart as well.
Classes (and interfaces) are recognized by their name and class loader. So if you place the service-interface in the same bundle as the implementation you lose the ability to hot-replace running bundle. Even though the interface has the same name, and it is identical in every sense newly deployed bundle has a different class loader => consumer considers the newly deployed bundles interface as a new class, and its dependencies are no longer met.
For more information on service compatibility and versions (see comments): http://wiki.osgi.org/wiki/Service_Compatibility