启动时更新OSGi捆绑包

我有几个OSGi包，每个都可以从OSGi包存储库更新。 当我启动OSGi框架（ApacheFelix）时，我希望启动第一个捆绑包，并检查所有已安装捆绑包的更新。如果有可用的更新，它应该更新每个更新（包括自身），然后继续启动（或者可能关闭，操作系统将重新启动应用程序）

如何以符合OSGi的方式最好地实现这一点

---

第一个包应该如何自我更新？它可以在启动时更新自身吗？

您可以查看OSGi核心规范中的状态图（这应该是图28）。在这里，您可以看到处于启动状态的bundle只能移动到活动状态（抛出异常时会出现异常）。捆绑包只能在处于已安装或已解析状态时更新。为此，必须在其处于活动状态时停止

这里的问题是，当bundle处于启动状态时，您无法停止它。只要Activators start（）方法被执行，bundle就仍然处于启动状态，而不是活动状态

---

您可以做的是在Bundle中启动一个线程，检查其活动状态，然后调用update（）方法。但别忘了终止线程，否则垃圾收集器将无法释放当前包的jar文件的资源。

您应该做以下几件事：

确保您有一个bundle（规范中经常称之为“管理代理”），它首先在框架上启动（重新启动），方法是为它提供比所有其他bundle更低的启动级别。还要确保告诉系统以与管理代理相同的启动级别启动。这样，这个捆绑包就能够在框架中的所有其他捆绑包实际启动之前更新它们。只有在管理代理完成更新之后，它才会刷新所有包并转到下一个启动级别，从而有效地启动所有其他捆绑包

要更新管理代理，最好的方法是临时安装第二个实际执行更新的捆绑包。在管理代理中生成线程并不是最好的解决方案，因为一旦捆绑包停止，这些线程就不应该继续运行，如果不遵守，可能会给您带来难以解决的问题。第二个包将实际更新，如果更新失败，甚至可能回滚

apacheace中提供了一个可以自我更新的管理代理示例。它有一个代理，可以从代码中安装第二个包，从远程位置更新自身。指向该项目相关部分的一些指针：

• 用于安装临时捆绑包的代码
• 用于临时束的激活器
• 对于代理人自身的bnd项目

---

对于（2），两步式管理代理如何？mgmtagent.1-更新并启动mgmtagent.2，mgmtagent.2更新mgmtagent.1，然后启动其他捆绑包。我发现很难想象第二个捆绑包的临时安装是如何工作的。这是从哪里来的？我用一个例子扩展了答案，丹。