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 <[email protected]> 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

Reply via email to