OSGi框架如何设置Bundle ID?

发布于 2024-12-06 13:24:04 字数 329 浏览 2 评论 0原文

我正在尝试在 main 方法中运行 OSGi 框架(Equinox)。 每次启动框架时,当我打印 BundleContext.getBundles().length 时,它表示该框架仅安装了 1 个 Bundle(这肯定是系统包)。 当我安装第一个捆绑包时,捆绑包 ID 将从上一个会话继续。假设我上次会话有 4 个捆绑包(并且在停止系统捆绑包之前我已停止并卸载了所有捆绑包),则第一个捆绑包 ID 设置为 5。 现在,我想知道框架如何选择bundle ID?即使我已经卸载了所有捆绑包,框架为什么以及如何记住最后一个会话?是因为 Bundle Cache 的原因吗?如果是的话,如何清除缓存(从 1 重新开始编号)?

I am trying to run OSGi framework (Equinox) in a main method.
Each time I start the framework, when I print BundleContext.getBundles().length, it says the framework has only 1 Bundle installed on (that is certainly the system bundle).
When I install my first bundle the bundle ID will continue from the last session. let's say if I had 4 bundles last session (and I have stopped and uninstalled all of them before stopping the system bundle), the first Bundle ID is set 5.
Now, I want to know how does the framework choose the bundle ID? Why and how does the framework remembers the last session, even though I had uninstalled all of the bundles? Is it because of Bundle Cache? And if it is, how can I clear the cache (to restart numbering from 1)?

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

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

发布评论

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

评论(3

岁吢 2024-12-13 13:24:04

框架在其管理的持久存储中的某个位置有最后使用的包 ID。这个商店看起来是一个框架实现细节。启动框架时,您可以指定 org.osgi.framework.storage.clean 框架配置属性。这将清除所有已安装的捆绑包,但我不确定它是否会重置上次使用的捆绑包 ID。

The framework has the last used bundle id somewhere in the persistent store it manages. What this store looks like is a framework implementation detail. When you launch the framework, you can specify the org.osgi.framework.storage.clean framework configuration property. This will clear all installed bundles but I am not sure if it will reset the last used bundle id.

逆夏时光 2024-12-13 13:24:04

删除 equinox/org.eclipse.osgi 文件夹会重置编号。删除之前,请确保您的捆绑包在此文件夹下没有任何重要数据。

具有有效包 ID 的 bundle 命令可以显示 equinox/org.eclipse.osgi 文件夹的绝对路径:

osgi> bundle 7
slf4j.api_1.6.1 [7]
  Id=7, Status=ACTIVE      Data Root=D:\temp\test\equinox\org.eclipse.osgi\bundles\7\data
...

Deleting the equinox/org.eclipse.osgi folder resets the numbering. Before the delete make sure that your bundles don't have any important data under this folder.

The bundle command with a valid bundle id can show the absolute path of the equinox/org.eclipse.osgi folder:

osgi> bundle 7
slf4j.api_1.6.1 [7]
  Id=7, Status=ACTIVE      Data Root=D:\temp\test\equinox\org.eclipse.osgi\bundles\7\data
...
雅心素梦 2024-12-13 13:24:04

以下是 OSGI Core Release 8 规范中关于捆绑包标识符的规定:

Bundle identifier - A long that is a Framework assigned unique
identifier for the full lifetime of a bundle, even if it is updated
or the Framework is restarted. Its purpose is to distinguish
bundles in a Framework. Bundle identifiers are assigned in
ascending order to bundles when they are installed. The method 
getBundleId() returns a bundle's identifier.

因此,at 告诉我们有关捆绑包标识符的两个重要属性: 1.) 从安装到卸载,bundleId 和捆绑包之间的关系是稳定的, 2.) 捆绑包标识符按安装时的升序分配。

回到最初的问题,尝试让包标识符编号分配重新开始违反了包标识的 OSGI 规范,并且您不应该尝试控制包标识。例如,假设您安装了三个捆绑包:

b1(0)、b2(1)、b3(2)

现在假设您卸载捆绑包 b2(id = 1):

b1(0),b3(2)

现在 让我们假设您重新安装 b2:

b1(0),b3(2),b2(3)

请注意,b2 获得了分配给它的新 id。只要 b2 没有被卸载,该 id 就可以稳定地引用 b2。如果您注意到的话,ID 1 不再被使用。 Bundle id 是一个标识符,而不是数组的索引。 b3 的bundleId 不能更改,因为它没有被卸载,b2 不能被分配bundleId 1,因为这会违反bundle 标识符在安装时按升序分配的规则(OSGI 框架不不记得之前安装过 b2 并卸载过 - 它看起来像是第一次安装)。鉴于bundleId很长,这意味着在OSGI的bundle id编号分配方案用完id之前,我们需要执行9,223,372,036,854,775,807个bundle卸载。

Here's what OSGI Core Release 8 specification says about bundle identifiers:

Bundle identifier - A long that is a Framework assigned unique
identifier for the full lifetime of a bundle, even if it is updated
or the Framework is restarted. Its purpose is to distinguish
bundles in a Framework. Bundle identifiers are assigned in
ascending order to bundles when they are installed. The method 
getBundleId() returns a bundle's identifier.

So that at tells us two important properties about bundle identifiers: 1.) the relationship between bundleId and bundle is stable from the time that it is installed to the time that it is uninstalled, and 2.) that bundle identifiers are assign in ascending order to when they were installed.

Going back to the original question, trying to get bundles identifier number assignments to start over works against the OSGI specification for bundle identity, and you shouldn't mess around with trying to control bundle identity. For example, let's assume you have three bundles installed:

b1(0), b2(1), b3(2)

Now lets assume you uninstall bundle b2 (with id = 1):

b1(0),b3(2)

Now lets assume you re-install b2:

b1(0),b3(2),b2(3)

Notice that b2 gets a new id assigned to it. That id is stable for referencing b2 as long as b2 is not uninstalled. And if you notice, the id of 1 is no longer used. Bundle id is an identifier, not an index into an array. The bundleId of b3 can't be changed because it wasn't uninstalled, b2 could not be assigned the bundleId of 1, since that would violate the rule the bundle identifiers are assigned in ascending order to when they were installed (the OSGI framework doesn't remember that b2 was previously installed and uninstalled - it looks like its just being installed for the first time). Given that the bundleId is a long, that means we would need to do 9,223,372,036,854,775,807 bundle uninstalls before OSGI's bundle id number assignment scheme would run out of id's.

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