[jira] [Created] (CELIX-112) Support code sharing

["Alexander Broekhuis (JIRA)" <ji...@apache.org>]

Alexander Broekhuis created CELIX-112:
-----------------------------------------

             Summary: Support code sharing
                 Key: CELIX-112
                 URL: https://issues.apache.org/jira/browse/CELIX-112
             Project: Celix
          Issue Type: Improvement
          Components: Framework
    Affects Versions: 1.0.0-incubating
            Reporter: Alexander Broekhuis
            Assignee: Alexander Broekhuis
             Fix For: next-incubating


Celix currently doesn't support code sharing. To make it easier to use data types it makes sense to support this. Currently it is needed to add service functions for all data types provided by a component.

To support code sharing on a OSGi level it is needed to:
* Declare exported and imported libraries
* Use a resolver to find/match exported libraries
* Resolve bundles when needed
* Update CMake macros to support this

With CELIX-111 solving multi library support, most of the work will already be in place.
Exported and imported libraries can be defined in the manifest using "Export-Library" and "Import-Library".
One of the major benefits of OSGi is versioning, to be able to reuse those principles in Celix the imported and exported libraries need to define versions/ranges. The format of the import and export string can be taken from the OSGi specification:
* Import-Library: first;version="[1.0,2.0)",second;version=...
* Export-Library: first;version="1.0",second;version=...

With the metadata available in the manifest, the existing (but unused) resolver can be updated to use that information. The output of the resolver can be used to load needed libraries. This will result in a fairly big change, currently the library of a bundle is loaded when the bundle is started, not when it is resolved. Since with the resolver it is possible for a bundle to be resolved and not yet started, libraries should be loaded when a bundle is resolved. This is needed to be able to use libraries of resolved bundles.

Also, the framework marks a bundle resolved if it is being processed by the resolver, so not all bundle enter the resolved state as part of the startBundle function. Currently libraries are loaded in the startBundle function, this has to be moved to a separate function which can be used by the resolver as well.
Note: The resolver itself is independent from the framework, so marking bundles resolved is done by the framework, but NOT always from the startBundle function. See the framework_markBundleResolved function for the implementation. This function can be used to load the libraries.

Regarding versioning:
The existing resolver supports resolving version ranges (it was ported from Felix when Celix started). But there is one big problem regarding libraries and versioning, when a library is linked to another library, the name of that library is added to the table of the first library. To be able to support multiple versions of a library the name of the library must have a version in it, eg libtest-1.0.0.dylib etc, so the name in the entry also contains the explicit version.
When in the runtime system a slightly newer version, eg 1.0.1, is available, the resolver will accept this if the importer range says so, import-library: test;version="[1.0,2.0)". Accepting this will result in the libraries being loading, which will result in a failure because the library has an entry for 1.0.0 and not 1.0.1.
This is explained in more detail in the Native-OSGi RFC, and a possible solution is to update the library entry with the information found by the resolver.

Since this requires a lot more work for now Celix will only support fixed version dependencies.
Note: Should we solve this in code, or leave this a convention and keep version range support intact the way it is? Leaving it intact makes it easier to add the library updating without any additional work.



--
This message was sent by Atlassian JIRA
(v6.2#6252)