OSGi 真正的优势

OSGi real advantage

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

虽然问题是:

Why do I need to restart all dependent bundles when updating a service (inside a 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();
    }
}

从我所有的包都重新启动(或至少从属包)这一事实来看,更新包中的 class 定义有什么意义,因为所有应用程序包都将是 stopped started 重置所有状态和活动连接 ?

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

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

这就是为什么您要从与服务实现包不同的包中导出包含服务接口 class 的包。然后所有服务消费包 服务实现包从导出包中导入包。然后当你更新服务实现包时,你不需要刷新服务消费包。

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