it misses the lightweight ...
On Friday, July 13, 2018, Roy Teeuwen <r...@teeuwen.be> wrote:
> 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 <karlpa...@gmail.com> wrote:
> >
> > On Friday, July 13, 2018, Roy Teeuwen <r...@teeuwen.be <mailto:
> 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 <mailto:karlpa...@gmail.com>
>
--
Karl Pauls
karlpa...@gmail.com
