What made it that we don't use the actual spec and implement that one properly? Is the spec too difficult in practice?
> On 13 Jul 2018, at 17:25, Karl Pauls <[email protected]> wrote: > > On Friday, July 13, 2018, Roy Teeuwen <[email protected] > <mailto:[email protected]>> wrote: > >> Hey David, >> >> Am I correct to understand that we are actually trying to make a >> lightweight OSGi Subsystem implementation with this? > > > We are :-) > > regards, > > Karl > > >> 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 >> >> > > -- > Karl Pauls > [email protected] <mailto:[email protected]>
