Bundle Management API Usability Improvement

[PengZheng]

Our current API relies on bundle ID, which servers as a safe handle to dynamic bundle objects. Though the usage of bundle ID provides safety, it also brings inconvenience to our users. They have to traverse the list of installed bundles to find out ID of the bundle they want to manipulate using location or symbolic name.

Another usability issue I found is that we don't support bundles with the same symbolic name but of different versions:

    /*
     * NOTE only allowing a single bundle with a symbolic name.
     * OSGi spec allows same symbolic name and different versions, but this is risky with
     * the behaviour of dlopen when opening shared libraries with the same SONAME.
     */
    bool alreadyInstalled = celix_framework_isBundleAlreadyInstalled(bundle->framework, symName);
    if (alreadyInstalled) {
        status = CELIX_BUNDLE_EXCEPTION;
        fw_logCode(bundle->framework->logger, CELIX_LOG_LEVEL_ERROR, status, "Cannot create module, bundle with symbolic name '%s' already installed.", symName);
    }

Suppose I want to programmatically install a bundle of the same symbolic name as of an installed bundle but of a different version and it failed, what can I do? I have no idea of the conflicting symbolic name, since I can not have a look at the logging messaging to find out what's wrong. Neither can I find it out from a bundle not installed yet. Without the conflicting symbolic name, I don't know which bundle to uninstall first before installing the new one.

IIRC, dlopen can open libraries of the same soname but of different paths on Linux. I can't see why we don't support it at the first place. Maybe it will cause trouble on macOS?

[pnoltes]

IIRC, dlopen can open libraries of the same soname but of different paths on Linux. I can't see why we don't support it at the first place. Maybe it will cause trouble on macOS?

I think this is also not an issue for macOS, but I am not sure. Even then, IMO it is fine to then to support multiple versions of the same bundle symbolic name for Linux only.

If I remember the other issue was private libs in bundle (i.e. libs added using celix_bundle_private_libs) with identical SONAME. This could lead to issue that bundle version 1.1.0 will use a private lib of bundle version 1.0.0, because it already has loaded a needed SONAME.

We discussed this a while back and if i remember correctly this is solvable, but not easy.

[pnoltes]

Good point. Both the bundle management API and service tracking API (mentioned on the celix dev mailling list) can IMO indeed be improved.

Do you think this is improvable by adding a few extra bundle calls in the bundle context or framework public headers? Or do we need to rethink the bundle ID approach used in the current API?

[PengZheng]

If I remember the other issue was private libs in bundle (i.e. libs added using celix_bundle_private_libs) with identical SONAME. This could lead to issue that bundle version 1.1.0 will use a private lib of bundle version 1.0.0, because it already has loaded a needed SONAME.

Oh I remember that! We don't have the luxury of Java class loader to have unlimited number of linker namespace.

Do you think this is improvable by adding a few extra bundle calls in the bundle context or framework public headers? Or do we need to rethink the bundle ID approach used in the current API?

I feel that the bundle ID idea is OK and this issue can be fixed by improving our existing API or implementation.

As for the service tracking API, for a large legacy application embedding a Celix framework instance, the most possible performance bottleneck is the system bundle context. After finishing the job at hand, I will return to this.

PS: I am currently working on #590, and Xu is working on Event Admin.