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)
