celix-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From GitBox <...@apache.org>
Subject [GitHub] [celix] rlenferink opened a new issue #59: Support code sharing
Date Sat, 28 Sep 2019 13:58:42 GMT
rlenferink opened a new issue #59: Support code sharing
URL: https://github.com/apache/celix/issues/59
   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](https://issues.apache.org/jira/browse/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
   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 is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:

With regards,
Apache Git Services

View raw message