Note that there is also a new OSGi RFP where this lightweight approach is
proposed for a new OSGi specification:
https://github.com/osgi/design/blob/master/rfps/rfp-0188-Features.pdf
Best regards,
David
On Fri, 13 Jul 2018 at 17:45, Karl Pauls <karlpa...@gmail.com> wrote:
> 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
>
