包含 OSGi 捆绑包中的附加资源

发布于 2024-08-04 10:24:32 字数 399 浏览 7 评论 0原文

我正在开发一个 OSGi 包,它将服务实现为本地可执行文件的包装器。也就是说,该服务使用 ProcessBuilder 运行可执行文件,为其提供一些数据,并检索结果。我的问题是关于打包这个捆绑包的最佳方式。本机可执行文件包含许多相关数据文件,所有这些文件都必须存在于磁盘上才能运行该工具。我找到了大量关于处理 OSGi 中本机 DLL 的参考资料,但没有一个参考资料涉及与必须存在于磁盘上而不是只能通过类路径检索的捆绑包关联的文件。

我想我可以将可执行文件和依赖文件直接包含在捆绑包存档中,然后在捆绑包启动时以编程方式提取到某个目录。我能想到的另一个选择是将可执行文件放在某处并设置指向它或其他东西的系统属性,但我想将配置保持在最低限度。

一个不特定于特定 OSGi 实现的解决方案会很好,但如果不是,我将使用 Equinox。

谢谢!

I'm working on an OSGi bundle which implements a service as a wrapper around a native executable. That is, the service runs the executable with ProcessBuilder, feeds it some data, and retrieves the result. My question is about the best way to package this bundle. The native executable includes a number of dependent data files which all must be present on disk for the tool to run. I've found plenty of references on dealing with native DLLs in OSGi, but none that address files associated with a bundle that must be present on disk rather than just retrievable through the classpath.

I was thinking that I could include the exectuable and dependent files directly in the bundle archive and then programmatically extract to some directory when the bundle is started. The other option I can think of is to put the executable somewhere and set a system property that points to it or something, but I want to keep configuration to a minimum.

A solution that isn't specific to a particular OSGi implementation would be nice, but if not, I'm using Equinox.

Thanks!

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(2

递刀给你 2024-08-11 10:24:32

这些附加文件是否需要可由本机代码写入?如果没有,没有什么可以阻止您将您喜欢的任何文件放入捆绑包中。

OSGi 中常见的问题是计算文件的路径,因为 OSGi 不假设文件系统可用(这并不像听起来那么奇怪,因为 OSGi 是在嵌入式设备中开始的)。

如何控制本机代码在何处查找其相关文件?你需要给它传递一条路径吗?

如果您想要一个目录来复制或解压内容,请使用:

org.eclipse.core.runtime.Platform.getStateLocation()

这将为您提供捆绑包的工作目录。

如果您想查找包中特定文件的路径,可以执行

org.eclipse.core.runtime.FileLocator.toFileURL((context.getBundle().getEntry("/etc/readme.txt")))

以下操作: 在本例中,将返回当前包中 /etc/readme.txt 的文件 URL。

这两段代码都假设它们位于激活器的 start() 方法内。

Do these additional files need to be writeable by the native code? If not, there's nothing stopping you putting any files you like inside a bundle.

The usual problem you have in OSGi is working out the path to the file as OSGi does not assume a file system is available (it's not as strange as it sounds as OSGi started out in embedded devices).

How do you control where the native code looks for its related files? Do you need to pass it a path?

If you want a directory to copy or unpack stuff, then use:

org.eclipse.core.runtime.Platform.getStateLocation()

Which gives you the working directory for the bundle.

If you want to find the path for a particular file in your bundle, you can do:

org.eclipse.core.runtime.FileLocator.toFileURL((context.getBundle().getEntry("/etc/readme.txt")))

Which, in this case, will return an file URL to the /etc/readme.txt in the current bundle.

Both pieces of code assume they are inside the activator's start() method.

故事与诗 2024-08-11 10:24:32

当然,您的解决方案有效。但您还必须小心停止并删除在安装过程中提取和启动的任何资源。如果可执行文件也创建了任何类型的工作文件,这可能特别难以跟踪。

您应该这样做,因为 OSGi 的优势之一是生命周期管理,它允许您不留痕迹地删除捆绑包和服务。为此,框架会跟踪捆绑包所做的一切。如果在删除安装并启动可执行文件的捆绑包后保持可执行文件运行,则连接会丢失,并且它可能会继续运行,直到计算机重新启动(对于嵌入式系统通常不是一个选项)。

Your solution works, of course. But you have to be careful to also stop and remove any resource that you extracted and started during the installation. This might especially difficult to track in case an executable also created any kind of working files.

You should do this because one of OSGi's strength is the lifecycle management, which allows you to also remove bundles and services without a trace. For this, the framework tracks everything a bundle does. If you keep an execuable running after you removed the bundle that installed and started it, the connection is lost and it may keep running until the machine is rebooted (often not an option for embedded systems).

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文