OSGi真正的优势

我正在试验OSGi来构建模块化物联网单元。如果想要在不牺牲通信代码的情况下更新系统的某些部分（例如传感器代码），那么这似乎是一种完美的技术，反之亦然

但问题是：

为什么在更新服务（包内）时需要重新启动所有依赖的包

根据我的所有捆绑包都已重新启动（或至少是相关捆绑包）这一事实判断，更新捆绑包中的类定义有什么意义，因为所有应用捆绑包都将

停止

和

启动

重置所有状态和活动连接

---

这与从命令行重新启动我的应用程序完全相同，因此我为什么需要osgi？

似乎保存服务接口类的包是由您的服务实现包导出的。因此，当服务实现捆绑包更新时，导出的包也会更新。因此，与您的服务实现捆绑包不同，所有使用服务的捆绑包都使用导出包的旧版本。因此，您必须刷新所有这些服务使用包，以确保它们使用与您的服务实现包相同的导出包版本

这就是为什么您希望从与服务实现捆绑包不同的捆绑包导出包含服务接口类的包。然后，所有服务消费捆绑包和服务实现捆绑包从导出捆绑包导入包。然后，当您更新服务实现捆绑包时，不需要刷新服务使用捆绑包

---

因此，通常情况下，您不希望经常更新的捆绑包导出必须由关心更新捆绑包功能的其他捆绑包导入的包，例如服务。

听起来很公平。我需要为我的应用程序的每个“模块”（从概念上讲）创建2个捆绑包。1个包包含服务接口类，1个包包含服务实现类。这样，当我更新实现时，我只需要重新启动这两个。。。好的，我试试看。好的，在这方面似乎还可以。还有一个问题。如果我想更新一个模块，我调用

bundle.update（）

这会触发重启，但为了刷新依赖包，我运行

packageAdmin.refreshPackages（）

，这也会导致重启。有没有一种方法可以避免触发重新启动两次？您可以停止捆绑包，更新捆绑包，刷新包，然后重新启动捆绑包。但是，如果您将实现分离到自己的包中，它甚至可能不会导出任何包，因此对其调用刷新包是毫无意义的。您只需要在更新导出捆绑包并且希望刷新导入捆绑包时刷新包。没错。你知道我如何通过对包的引用来测试包是否正在导出包吗？这是为了仅在需要时刷新包bundle.adapt（BundleWiring.class）将返回bundle的BundleWiring对象，然后您可以询问BundleWiring有关导出包的信息。

private void updateBundle(String f) {
    BundleContext mainBc = felix.getBundleContext();
    Bundle bundle = mainBc.getBundle(f);
    try {
        bundle.update();
    // if I don't do this, the services inside 'bundle' will NOT be updated
        PackageAdmin pa = mainBc.getService(mainBc.getServiceReference(PackageAdmin.class));
        pa.refreshPackages(mainBc.getBundles());
    // at this point all bundles were restarted
    } catch (BundleException e) {
        System.err.println("Error while updating  " + f);
        e.printStackTrace();
    }
}