OSGi 平台版本之间兼容性的建议
假设这是可能的，您对使捆绑包在不同平台版本之间兼容有何建议？特别是在 R3 和 R4 之间。
更新我的要求：
这个想法是为当前运行 OSGi R3 容器的嵌入式设备开发一个 Web 界面，但它可以很快升级到 R4（我们对此没有太多控制权） ）。 Web 界面将使用 OSGi HTTP 服务进行部署。我看到三个选项：
- 使用 R4 执行应用程序，因为我发现某些 Web 工具包不适用于旧版本。我认为该设备的提供商可以毫不费力地在 R4 上部署当前的 R3 捆绑包（但不确定）。
- 使用 R3 实现 Web 界面，而无需使用现代 Web 工具包（或推荐我一个）。
- 使用一些 R4 捆绑包进行此操作，但在某种程度上与版本无关，因此我们最终可以将其部署在 R3 或 R4 上。
Assuming that it's even possible, what would be your recomendations to make a bundle compatible between different platform releases? Specially between R3 and R4.
Update about my requirements:
The idea was to develop a web interface for a embedded device that currently runs an OSGi R3 container but that it could be upgraded soon to R4 (we don't have much control over this). The web interface will be deployed using a OSGi HTTP service. I see three options:
- Do the application with R4 as I've seen that some web toolkits doesn't work with older releases. I suppose that the providers of the device could deploy the current R3 bundles on R4 without much effort (but not sure).
- Implement the web interface with R3 and without the benefits of modern web toolkits (or recommend me one).
- Do it with some R4 bundles but some-way release-independent so we can finally deploy it on R3 or R4.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
一般来说，R4 主要为捆绑清单引入了新标头，而 R3 实现会忽略这些标头。导入/导出行为存在一些语义差异，但根据您制作的捆绑包类型，这些差异可能并不重要。您可以使用的一种策略是简单地创建一个 R3 捆绑包，它在 R4 框架上仍然可以正常工作。当然，在这种情况下，您会错过 R4 的一些新功能。
后续：
从HttpService的角度来看，从R3到R4.2并没有太大的变化。前者使用HttpService 1.1规范，后者1.2。差异很小（规范在 API 文档中使用 @since 标签来解释何时引入了哪些方法）。
R3 捆绑包确实可以像 R4 上一样工作。但请记住，实际上，在 R4 中运行 R3 捆绑包时，您可能会发现错误。当 R4 刚刚发布时，我将一个大项目从 R3 迁移到 R4，我们遇到了很多小问题，都是我们自己的错误，这导致捆绑包在 R4 上失败，而它们在 R3 上运行得很好。这些主要与 R4 实现有关，一般来说，在委托给其父类加载器时更加严格。确保在要部署它们的框架上测试您的捆绑包。
我想知道，您查看的 Web 工具包在什么情况下无法在 R3 上运行？它们依赖于 HttpService 1.2 吗？我想自己在 R3 上运行 1.2 或将其桥接到 1.1 实现并不难。
In general, R4 mostly introduced new headers for the bundle manifest, which R3 implementations ignore. There are a few semantic differences in import/export behavior but depending on what kind of bundle you're making, those might not matter. One strategy you could use is to simply create an R3 bundle, which should still work fine on an R4 framework. You'd miss out on some new R4 features in that case, of course.
Follow up:
From the point of view of the HttpService, there are no big changes going from R3 to R4.2. The former uses the 1.1 specification of HttpService, the latter 1.2. The differences are minor (the spec uses the @since tags in the API documentation to explain what methods were introduced when).
It is completely true that R3 bundles work as is on R4. Keep in mind though that in practice you could discover bugs when running R3 bundles in R4. When R4 was just released, I moved a big project from R3 to R4 and we encountered lots of small issues, all our own fault, which caused bundles to fail on R4 while they were happily running on R3. These were mostly related to R4 implementations in general being more strict when it comes to delegating to their parent classloader. Make sure you test your bundles on the frameworks you want to deploy them on.
I am wondering, in what way do the web toolkits you looked at not work on R3? Do they depend on HttpService 1.2? I guess it would not be hard to run 1.2 on R3 yourself, or bridge it to an 1.1 implementation.
我从 R1 开始就开发了捆绑包，它们仍然在 R4 框架上运行。向后兼容性是规范工作的一个要点。但正如马塞尔指出的那样，有关您的要求的更多详细信息将会有所帮助。
更新
是否存在无法使用 R4 的业务或技术要求？好吧，如果您只是使用标准 HttpService 实现基于 servlet 的服务，则在将捆绑包移动到 R4 框架时应该不会出现任何问题。但是，您可以而且应该开始使用 R4 清单属性。它们在 R3 中被忽略，但对于解决 R4 及更高版本中的依赖关系非常有帮助。
如果您仅限于 R3 框架，我总是会定期在 R4 框架上并行进行测试运行，以确保一切正常。根本没有太多努力。
I've developed bundles since R1 and they still run on R4 frameworks. Backward compatibility is an essential point for the specification work. But as Marcel points out, some more details on your requirements would be helpful.
Update
Is there a business or technical requirement that you cannot use R4? Well, If you just implement a servlet-based service using the standard HttpService you should not expect any problems when moving the bundle to an R4 framework. However you can and should start using the R4 manifest properties. They are ignored in R3 but are very helpful in resolving dependcies in R4 and later.
If you are limited to an R3 framework I would always do a test run on an R4 framework in parallel on a regular basis to ensure that everything is still ok. Not much effort at all.