Here comes the beauty of the feature model: it does not prescribe any
runtime technology to be used. It could be what we're currently building
here in Sling, it could be Karaf, it could subsystems. A feature model
can easily be used to create a packaging for any of those solutions.
As some might know we started to try to use subsystems some years ago
and apart from not being lightweight we ran into some other issues
(which might be fixed today). For the use cases at hand, it's rather
clumsy to use. But still, with the feature model and the region model in
there, you can write a simple tool that creates a subsystem out of the
feature. However, the sharing model is different: while the sharing
model of subsystems is more hierarchical like a tree, the model defined
here allows to have any intersections, therefore it is more flexible.
But the key idea is still that you can describe features (what do they
contain, what do they provide, what do they need) and then various
tooling can be used to actually run those features. It's one description
to rule the world :)
Regards
Carsten
Roy Teeuwen wrote
> Hey David,
>
> Am I correct to understand that we are actually trying to make a lightweight
> OSGi Subsystem implementation with this?
>
> Greets,
> Roy
>
>> On 13 Jul 2018, at 10:47, David Bosschaert <david.bosscha...@gmail.com>
>> wrote:
>>
>> Hi all,
>>
>> I started working on a prototype for the API Region support for the Sling
>> Feature model as outlined in [1]. The prototype includes runtime support
>> for enforcing the API Regions as declared in the feature model files. This
>> mail is to share my current approach, which is partly implemented on my
>> branch (features-service) and in the sling-whiteboard.
>>
>> An API region is specified in a feature file using an extension. For
>> example:
>> "api-regions:JSON|false" : [
>> {
>> "name": "platform",
>> "exports": [
>> "org.apache.sling.commons.scheduler"
>> ]
>> }
>> ]
>>
>> This means that the org.apache.sling.commons.scheduler package from a
>> bundle in this feature is exposed outside of the feature in the 'platform'
>> region. It means that other features also in the 'platform' region have
>> access to it, but features not in the 'platform' region don't. Within a
>> single feature all bundles have access to all exported package from other
>> bundles in the same region.
>>
>> To realise this at runtime, I created a WhitelistEnforcer component which
>> knows of the whitelist configuration at runtime. The Feature launcher will
>> initialize this component with the api region information. The
>> WhitelistEnforcer registers a framework resolver hook which can prevent
>> bundles from resolving to API from other bundles if this API should not be
>> exposed to the requesting bundle.
>> Additionally, I created a Features service, which can at runtime tell the
>> caller what feature a given bundle belongs to. The OSGi resolver hook only
>> tells you whether a given bundle needs something, so in order to map that
>> to the api-regions configuration which is defined on the feature level, we
>> need to know what feature this bundle belongs to.
>> Both the WhitelistEnforcer as well as the Features service are defined by
>> framework extension fragment bundles so that they are present early in the
>> system.
>>
>> There is also an associated JIRA:
>> https://issues.apache.org/jira/browse/SLING-7779
>> I'm hoping to merge this soon to the Sling codebase, any thoughts would be
>> appreciated :)
>>
>> Best regards,
>>
>> David
>>
>> [1]
>> https://github.com/apache/sling-org-apache-sling-feature/blob/master/apicontroller.md
>
--
Carsten Ziegeler
Adobe Research Switzerland
cziege...@apache.org
