api 和实现的单独 OSGI 捆绑是常见做法吗？
我有一个带有依赖项的类，我想在不重新启动依赖项的情况下进行热部署。该类有一个接口，但只有一个具体实现。
最初，我创建了一个导出接口的包，并使用未导出的激活器和实现类注册了实现。但是，如果我更新捆绑包，则在调用 PackageAdmin#refreshPackages 时，使用注册服务的捆绑包会在更新后重新启动（使用 fileinstall 时这是自动的）。
我通过创建一个单独的 api 包解决了这个问题。
这是实现这一目标的最佳方法吗？
您是否拥有一个导出其 api 并将实现包含在同一个包中的包。据我所知，任何给定的包要么导出其所有类，要么不导出类。我缺少什么？
I have a class with dependencies which I want to hot deploy without restarting the dependencies. The class has an interface but there's only one concrete implementation.
Initially I created a single bundle with exported the interface and registered the implementation using activator and implementation classes which were not exported. However, if I update the bundle, bundles which use the registered service get restarted after the update when PackageAdmin#refreshPackages is called (this is automatic when using fileinstall).
I have fixed this by creating a separate api bundle.
Is this the best way to achieve this?
Would you ever have a bundle which exports its api and includes the implementation in the same bundle. As far as I can see any give bundle would either export all its classes or no classes. What am I missing?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
将 API 包与其在 OSGi 中的实现分开绝对是最佳实践。如果您这样做，那么任何使用 API 的包只需要从 API 包中导入类，这可以让您在运行时更改实现，而无需重新启动依赖包。
理想情况下，您的实现包将实现接口并将实现导出为 API 提供的接口上的服务。这允许客户端包在不引用实现包的情况下使用该服务。
It is definitely a best practice to separate API bundles from their implementations in OSGi. If you do this, then any bundle that uses the API only needs to import classes from the API bundle, which can allow you to change implementations at runtime without restarting your dependent bundles.
Ideally your implementation bundle would implement the interface and export implementation as a service on the API provided interface. This allows the client bundles to utilize the service without referencing the implementation bundle.
在 Apache Sling 中，我们两者兼而有之：主要 API 都在自己的捆绑包中，但对于扩展或可选组件等较小的东西，我们通常在与 API 相同的包中提供默认实现。
在后一种情况下，您仍然可以允许替换这些默认服务，例如，当您想要覆盖它们时使用服务排名值。
捆绑包不必导出其所有类，我们包含默认服务的捆绑包仅导出 API 包（显然，默认实现位于不同的包中）。
In Apache Sling we do both: major APIs are in their own bundles, but for smaller things like extensions or optional components we often provide the default implementation in the same bundle as the API.
In the latter case, you can still allow for those default services to be replaceable, for example using service ranking values when you want to override them.
A bundle does not have to export all its classes, our bundles which include default services export just the API packages (and the default implementations are in different packages, obviously).
除非存在能够在运行时替换实现的硬性要求，而无需重新启动客户端捆绑包，否则我个人主张保持 API 和实现之间的显式依赖关系链接（通过在 API 捆绑包中包含 impl 类，或者通过让 API 捆绑包从 impl 导入实现包）。
具有上面建议的模式的 pb 是它们破坏了依赖链。依赖关系管理的好处远远超出了简单的 API 兼容性，它们还包括确保可预测、一致的运行时行为，以及与部署生态系统的兼容性，所有这些都需要管理实现依赖关系。
Unless there is a hard requirement to be able to replace implementation at runtime, without restarting client bundles, I would personally advocate keeping the explicit dependency link between API and implementation (either by including impl classes in the API bundle, or by having the API bundle import implementation packages from the impl. bundle).
The pb with the patterns suggested above is that they break the dependency chain. The benefits of dependency management go far beyond simple API compatibility, they also include ensuring predictable, consistent runtime behavior, as well as compatibility with the deployment ecosystem, and all of those require managing the implementation dependencies.