You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@sling.apache.org by David Bosschaert <da...@gmail.com> on 2018/07/13 08:47:30 UTC
Initial prototype of Sling Feature model API Region support
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
Re: Initial prototype of Sling Feature model API Region support
Posted by David Bosschaert <da...@gmail.com>.
Hi Dominik.
It's an interesting point. I guess when features are more widely adopted
and you're building a system from features provided by multiple
organisations you can also run into the problem that multiple people define
the same API regions 'foo'. It might make sense to adopt a convention to
use reverse dns naming for regions, like in Java package names... Then we
can reserve region names without scoping (read: dots) for internal 'system'
features like the 'global' one.
Best regards,
David
On Fri, 13 Jul 2018 at 14:51, Dominik Süß <do...@gmail.com> wrote:
> Hi David,
>
> just having backward compatibility and potential further evolution in mind.
> Would it make sense for regions to follow some namespace concept an reserve
> a certain namespace. So even if the future brings new scenarios where we
> might need new reserved regions we could have some "system" namespace or
> so. Additionally it is easier to layer different "owners" on top and
> explicitly declare the ownership (e.g. vendor customer scenario where we
> would want to check weather customers hook into regions that are supposed
> to be internal).
>
> Cheers
> Dominik
>
> Cheers
> Dominik
>
> On Fri, Jul 13, 2018 at 12:20 PM David Bosschaert <
> david.bosschaert@gmail.com> wrote:
>
> > Hi Bertrand,
> >
> > On Fri, 13 Jul 2018 at 12:08, Bertrand Delacretaz <
> bdelacretaz@apache.org>
> > wrote:
> >
> > > Hi David,
> > >
> > > On Fri, Jul 13, 2018 at 11:54 AM David Bosschaert
> > > <da...@gmail.com> wrote:
> > > > ...Yes, 'global' is the magic name for the region available to
> > everyone.
> > > This
> > > > includes bundles that are in different regions or bundles that are in
> > no
> > > > region at all....
> > >
> > > Ok, so IIUC "global" is the only reserved region name, and other names
> > > can be selected freely?
> > >
> >
> > Yep, it's defined as a constant at [2]. All other names can be selected
> at
> > will.
> >
> >
> > > If I'm correct it might be good to mention that at [1], for clarity.
> > >
> >
> > Good point - I've updated [1] for this.
> >
> > Also (while I'm in nitpicking mode ;-) how about using "API Controller
> > > and API Regions" as the title of that document? It speaks more about
> > > regions than about the controller itself.
> > >
> >
> > Also good point - I've changed this too (I didn't change the file name
> as I
> > didn't want to break any links).
> >
> > Best regards,
> >
> > David
> >
> >
> > > Thanks for this, it looks quite useful!
> > >
> > > -Bertrand
> > >
> > > [1]
> > >
> >
> https://github.com/apache/sling-org-apache-sling-feature/blob/master/apicontroller.md
> >
> >
> > [2]
> >
> >
> https://github.com/apache/sling-whiteboard/blob/master/featuremodel/feature-whitelist/src/main/java/org/apache/sling/feature/whitelist/WhitelistService.java#L24
> >
>
Re: Initial prototype of Sling Feature model API Region support
Posted by Dominik Süß <do...@gmail.com>.
Hi David,
just having backward compatibility and potential further evolution in mind.
Would it make sense for regions to follow some namespace concept an reserve
a certain namespace. So even if the future brings new scenarios where we
might need new reserved regions we could have some "system" namespace or
so. Additionally it is easier to layer different "owners" on top and
explicitly declare the ownership (e.g. vendor customer scenario where we
would want to check weather customers hook into regions that are supposed
to be internal).
Cheers
Dominik
Cheers
Dominik
On Fri, Jul 13, 2018 at 12:20 PM David Bosschaert <
david.bosschaert@gmail.com> wrote:
> Hi Bertrand,
>
> On Fri, 13 Jul 2018 at 12:08, Bertrand Delacretaz <bd...@apache.org>
> wrote:
>
> > Hi David,
> >
> > On Fri, Jul 13, 2018 at 11:54 AM David Bosschaert
> > <da...@gmail.com> wrote:
> > > ...Yes, 'global' is the magic name for the region available to
> everyone.
> > This
> > > includes bundles that are in different regions or bundles that are in
> no
> > > region at all....
> >
> > Ok, so IIUC "global" is the only reserved region name, and other names
> > can be selected freely?
> >
>
> Yep, it's defined as a constant at [2]. All other names can be selected at
> will.
>
>
> > If I'm correct it might be good to mention that at [1], for clarity.
> >
>
> Good point - I've updated [1] for this.
>
> Also (while I'm in nitpicking mode ;-) how about using "API Controller
> > and API Regions" as the title of that document? It speaks more about
> > regions than about the controller itself.
> >
>
> Also good point - I've changed this too (I didn't change the file name as I
> didn't want to break any links).
>
> Best regards,
>
> David
>
>
> > Thanks for this, it looks quite useful!
> >
> > -Bertrand
> >
> > [1]
> >
> https://github.com/apache/sling-org-apache-sling-feature/blob/master/apicontroller.md
>
>
> [2]
>
> https://github.com/apache/sling-whiteboard/blob/master/featuremodel/feature-whitelist/src/main/java/org/apache/sling/feature/whitelist/WhitelistService.java#L24
>
Re: Initial prototype of Sling Feature model API Region support
Posted by David Bosschaert <da...@gmail.com>.
Hi Bertrand,
On Fri, 13 Jul 2018 at 12:08, Bertrand Delacretaz <bd...@apache.org>
wrote:
> Hi David,
>
> On Fri, Jul 13, 2018 at 11:54 AM David Bosschaert
> <da...@gmail.com> wrote:
> > ...Yes, 'global' is the magic name for the region available to everyone.
> This
> > includes bundles that are in different regions or bundles that are in no
> > region at all....
>
> Ok, so IIUC "global" is the only reserved region name, and other names
> can be selected freely?
>
Yep, it's defined as a constant at [2]. All other names can be selected at
will.
> If I'm correct it might be good to mention that at [1], for clarity.
>
Good point - I've updated [1] for this.
Also (while I'm in nitpicking mode ;-) how about using "API Controller
> and API Regions" as the title of that document? It speaks more about
> regions than about the controller itself.
>
Also good point - I've changed this too (I didn't change the file name as I
didn't want to break any links).
Best regards,
David
> Thanks for this, it looks quite useful!
>
> -Bertrand
>
> [1]
> https://github.com/apache/sling-org-apache-sling-feature/blob/master/apicontroller.md
[2]
https://github.com/apache/sling-whiteboard/blob/master/featuremodel/feature-whitelist/src/main/java/org/apache/sling/feature/whitelist/WhitelistService.java#L24
Re: Initial prototype of Sling Feature model API Region support
Posted by Bertrand Delacretaz <bd...@apache.org>.
Hi David,
On Fri, Jul 13, 2018 at 11:54 AM David Bosschaert
<da...@gmail.com> wrote:
> ...Yes, 'global' is the magic name for the region available to everyone. This
> includes bundles that are in different regions or bundles that are in no
> region at all....
Ok, so IIUC "global" is the only reserved region name, and other names
can be selected freely?
If I'm correct it might be good to mention that at [1], for clarity.
Also (while I'm in nitpicking mode ;-) how about using "API Controller
and API Regions" as the title of that document? It speaks more about
regions than about the controller itself.
Thanks for this, it looks quite useful!
-Bertrand
[1] https://github.com/apache/sling-org-apache-sling-feature/blob/master/apicontroller.md
Re: Initial prototype of Sling Feature model API Region support
Posted by David Bosschaert <da...@gmail.com>.
Hi Bertrand,
On Fri, 13 Jul 2018 at 11:00, Bertrand Delacretaz <bd...@apache.org>
wrote:
> Hi David,
>
> On Fri, Jul 13, 2018 at 10:47 AM David Bosschaert
> <da...@gmail.com> wrote:
> > ...I started working on a prototype for the API Region support for the
> Sling
> > Feature model as outlined in [1]....
>
> Interesting stuff!
>
> Is "global" a magic name for the region that everybody can see? IOW,
> does exporting packages to the "global" region have the same effect
> than omitting region information?
>
Yes, 'global' is the magic name for the region available to everyone. This
includes bundles that are in different regions or bundles that are in no
region at all.
The requirements at [1] state: Without any further information, API is
globally visible by default.
So omitting the region information has the same effect as exporting all the
exported packages from all the bundles in that feature to everyone. If you
only want to export a portion of your packages to everyone you can achieve
this by putting just those packages in the 'global' region.
Best regards,
David
> > [1]
> >
> https://github.com/apache/sling-org-apache-sling-feature/blob/master/apicontroller.md
>
Re: Initial prototype of Sling Feature model API Region support
Posted by Bertrand Delacretaz <bd...@apache.org>.
Hi David,
On Fri, Jul 13, 2018 at 10:47 AM David Bosschaert
<da...@gmail.com> wrote:
> ...I started working on a prototype for the API Region support for the Sling
> Feature model as outlined in [1]....
Interesting stuff!
Is "global" a magic name for the region that everybody can see? IOW,
does exporting packages to the "global" region have the same effect
than omitting region information?
-Bertrand
> [1]
> https://github.com/apache/sling-org-apache-sling-feature/blob/master/apicontroller.md
Re: Initial prototype of Sling Feature model API Region support
Posted by David Bosschaert <da...@gmail.com>.
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 <ka...@gmail.com> wrote:
> it misses the lightweight ...
>
> On Friday, July 13, 2018, Roy Teeuwen <ro...@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 <ka...@gmail.com> wrote:
> > >
> > > On Friday, July 13, 2018, Roy Teeuwen <roy@teeuwen.be <mailto:
> > roy@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.bosschaert@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
> > > karlpauls@gmail.com <ma...@gmail.com>
> >
>
>
> --
> Karl Pauls
> karlpauls@gmail.com
>
Re: Initial prototype of Sling Feature model API Region support
Posted by Karl Pauls <ka...@gmail.com>.
it misses the lightweight ...
On Friday, July 13, 2018, Roy Teeuwen <ro...@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 <ka...@gmail.com> wrote:
> >
> > On Friday, July 13, 2018, Roy Teeuwen <roy@teeuwen.be <mailto:
> roy@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.bosschaert@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
> > karlpauls@gmail.com <ma...@gmail.com>
>
--
Karl Pauls
karlpauls@gmail.com
Re: Initial prototype of Sling Feature model API Region support
Posted by Roy Teeuwen <ro...@teeuwen.be>.
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 <ka...@gmail.com> wrote:
>
> On Friday, July 13, 2018, Roy Teeuwen <roy@teeuwen.be <ma...@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 <da...@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
> karlpauls@gmail.com <ma...@gmail.com>
Re: Initial prototype of Sling Feature model API Region support
Posted by Karl Pauls <ka...@gmail.com>.
On Friday, July 13, 2018, Roy Teeuwen <ro...@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 <da...@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
karlpauls@gmail.com
Re: Initial prototype of Sling Feature model API Region support
Posted by Carsten Ziegeler <cz...@apache.org>.
Here comes the beauty of the feature model: it does not prescribe any
runtime technology to be used. It could be what we're currently building
here in Sling, it could be Karaf, it could subsystems. A feature model
can easily be used to create a packaging for any of those solutions.
As some might know we started to try to use subsystems some years ago
and apart from not being lightweight we ran into some other issues
(which might be fixed today). For the use cases at hand, it's rather
clumsy to use. But still, with the feature model and the region model in
there, you can write a simple tool that creates a subsystem out of the
feature. However, the sharing model is different: while the sharing
model of subsystems is more hierarchical like a tree, the model defined
here allows to have any intersections, therefore it is more flexible.
But the key idea is still that you can describe features (what do they
contain, what do they provide, what do they need) and then various
tooling can be used to actually run those features. It's one description
to rule the world :)
Regards
Carsten
Roy Teeuwen wrote
> 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 <da...@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
>
--
Carsten Ziegeler
Adobe Research Switzerland
cziegeler@apache.org
Re: Initial prototype of Sling Feature model API Region support
Posted by Roy Teeuwen <ro...@teeuwen.be>.
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 <da...@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