celix-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Alexander Broekhuis (JIRA)" <j...@apache.org>
Subject [jira] [Created] (CELIX-112) Support code sharing
Date Tue, 04 Mar 2014 15:11:20 GMT
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
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

View raw message