On Friday, July 13, 2018, Roy Teeuwen <r...@teeuwen.be> 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 <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
>
>
--
Karl Pauls
karlpa...@gmail.com
