不同的osgi捆绑包具有相同接口的实现-将该接口放置在何处？

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

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

---

什么是最好的、最像osgi的结构方式？到目前为止，我的最佳选择是创建一个新的“api”包，定义实现的公共接口

分离api包可能是最好的选择。它允许您在以后替换包实现。另外，使用单独的api捆绑包，您可以热替换当前捆绑包，而无需用户重新启动

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

---

有关服务兼容性和版本的更多信息（请参阅注释）：

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