如何更新 OSGI 中的接口？
我正在学习 OSGi，我对以下情况感到好奇：
我想更改（主要扩展）OSGi 公开的接口，而不更改类名。是否可以制作一个将旧界面“翻译”为新界面的捆绑包。
下面是一个示例，我希望仅通过使用一些清单标头就足够清楚了。 假设我有这些 OSGI 包：
Bundle-Name: Example Iface1 Implementation
Import-Package: org.osgi.framework
Export-Package: example.interfaces;version="1.0"
Bundle-Name: Example Iface1 User
Import-Package: org.osgi.framework, example.interfaces;version="1.0"
但是我需要更新公开的接口。 接口类名保持不变，但添加了功能。 所以我创建：
Bundle-Name: Example Iface2 Implementation
Import-Package: org.osgi.framework
Export-Package: example.interfaces;version="2.0"
我可以制作一个像这样的bundlde来将新界面转换为需要它的旧界面吗？
Bundle-Name: Interface Translator
Import-Package: org.osgi.framework, example.interfaces;version="2.0"
Export-Package: example.interfaces;version="1.0"
因为在这种情况下我不知道如何在java中进行导入...
或者有更好的方法来处理OSGi中的这种情况吗？
I'm learning OSGi and I'm curious about the following situation:
I want to change (extend mostly) an interface exposed by OSGi, without changing the classname. Is it possible make a bundle that "translates" the old interface to the new.
Below is an example, I hope it is clear enough, just by making use of a few manifest headers.
Suppose I have these OSGI bundles:
Bundle-Name: Example Iface1 Implementation
Import-Package: org.osgi.framework
Export-Package: example.interfaces;version="1.0"
Bundle-Name: Example Iface1 User
Import-Package: org.osgi.framework, example.interfaces;version="1.0"
But then I need to update the exposed interface(s).
The interface classnames stay the same, but there is functionality added to them.
So I create:
Bundle-Name: Example Iface2 Implementation
Import-Package: org.osgi.framework
Export-Package: example.interfaces;version="2.0"
Can I make a bunlde like this to translate the new interface to the old for bundles that need it?
Bundle-Name: Interface Translator
Import-Package: org.osgi.framework, example.interfaces;version="2.0"
Export-Package: example.interfaces;version="1.0"
Because in this case I have no idea how to do the imports in java...
Or is there a much better way to do deal with this situation in OSGi?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
不需要这样做，但您确实需要正确指定您的版本。
您的捆绑包的第一个版本导出“example.interfaces”版本 1.0。这很好。用户包应导入版本“[1.0, 2.0)”。换句话说，1.0 到但不包括 2.0 版本。
现在你说你想向接口添加一些方法。这种变化对于接口的消费者来说是向后兼容的，但对于生产者来说却不是。指示这种更改的方法是更改版本的第二部分，即“次要”部分。因此，更新后的接口包应导出“example.interfaces”版本 1.1。
现在您的新版本界面可以直接由用户包使用，因为 1.1 属于 [1.0, 2.0) 范围。没有必要导出与 1.0 相同的接口——事实上你不能这样做，因为那意味着接口没有改变。但它已经发生了变化，对于生产者来说是一种向后不兼容的方式。
例如，假设您有一个实现原始接口的生产者包。它应该使用以下导入范围：[1.0, 1.1)。该包一定不能看到更新后的接口，因为它无法实现新方法，而且实际上它也不会看到更新后的接口，因为 1.1 超出了范围 [1.0, 1.1)。如果您编写一个支持更新接口的新生产者，它必须使用范围 [1.1, 1.2)。
请阅读OSGi 语义版本控制论文（PDF 警告）了解更多详细信息如何指定导出版本和导入范围。
There is no need to do this, but you do need to specify your versions correctly.
Your first version of the bundle exports "example.interfaces" version 1.0. This is fine. The user bundle should import version "[1.0, 2.0)". In other words, 1.0 up to but not including version 2.0.
Now you say you want to add some methods to the interfaces. This kind of change is backwards-compatible for consumers of the interface but not for producers. The way to indicate this kind of change is to bump the second part of the version, i.e, the "minor" segment. So your updated interfaces bundle should export "example.interfaces" version 1.1.
Now your new version of the interface can be used directly by the user bundle because 1.1 falls within the range [1.0, 2.0). There is no need to export the same interface as 1.0 -- in fact you MUST not do this, because that would imply the interface has not changed. But it has changed, in a backwards incompatible way for producers.
For example, suppose you have a producer bundle that implements the original interface. It should use the following import range: [1.0, 1.1). That bundle must NOT see the updated interface because it would not be able to implement the new methods, and indeed it will not see the updated interface because 1.1 is outside of the range [1.0, 1.1). If you write a new producer that supports the updated interface it must use the range [1.1, 1.2).
Please read the OSGi Semantic Versioning paper (PDF warning) for more details of how to specify your export versions and import ranges.