OSGi的真正优势

时间:2018-10-10 15:02:22

标签: osgi apache-felix osgi-bundle

我正在尝试使用OSGi构建模块化的IoT单元。如果要在不牺牲通信代码的情况下更新系统的各个部分(例如传感器代码),这似乎是一种完美的技术,反之亦然。

问题是:

  

为什么更新服务(在bundle中)时需要重新启动所有相关的bundle?

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();
    }
}

从我所有捆绑软件(或至少是从属捆绑软件)重新启动的事实来看,更新捆绑软件中的类定义的意义是什么,因为所有应用捆绑软件将是stoppedstarted重置所有状态和活动连接?

这就像从命令行重新启动我的应用程序一样,为什么我需要osgi?

1 个答案:

答案 0 :(得分:1)

似乎包含服务接口类的软件包已由您的服务实现捆绑包导出。因此,当更新服务实现包时,导出的包也将更新。因此,与您的服务实现包不同,所有使用该服务的包都使用导出的包的旧版本。因此,您必须刷新所有这些消耗服务的捆绑软件,以确保它们使用与您的服务实现捆绑软件​​相同的导出软件包修订版。

这就是为什么要从与服务实现包不同的包中导出包含服务接口类的包的原因。然后,所有消耗服务的软件包服务实现软件包都从导出软件包中导入软件包。然后,在更新服务实现捆绑包时,无需刷新消耗服务的捆绑包。

因此,通常,您不希望将经常更新的捆绑包导出为必须由关心更新捆绑包功能的其他捆绑包(例如服务)导入的包。