You are viewing a plain text version of this content. The canonical link for it is here.

Posted to dev@sling.apache.org by Felix Meschberger <fm...@adobe.com> on 2014/01/17 16:32:56 UTC

FeatureFlags without ResourceAccessGate

Hi

As I repeatedly said, I think the Feature Flags support should be implemented without the ResourceAccessGate mechanism because it is not an access control thing but a purely operational visibility thing. Also as opposed to access control, feature flag enabled can and should be controllable by a consumer of the API; for example by passing a request parameter on the request.

Based on the existing code, I have created a prototype in my whiteboard at [1]:

* On a per-resource level feature flags are set as sling:feature properties of type String or String[]
* Flags are checked during resource resolution in the ProviderHandler.getReadableResource method
* Feature services can implement ResourceDecorator such that they can decorate a resource in case their feature is enabled.

I also provided diffs in the feature-flags and resourceresolver projects to be able to see, what has been changed.

WDYT ?

Regards
Felix

[1] http://svn.apache.org/repos/asf/sling/whiteboard/fmeschbe/featureflags

Re: FeatureFlags without ResourceAccessGate

Posted by Felix Meschberger <fm...@adobe.com>.

Hi

Am 27.01.2014 um 15:24 schrieb Carsten Ziegeler <cz...@apache.org>:

>> 
>> The global one basically just provides access to the raw request while the
>> Sling-embedded one also provides access to the SlingHttpServletRequest as
>> well as the request's ResourceResolver.
>> 
>> 
> Ah right, because you don't have the resolver in the global filter...but
> this means that all flags are tested twice if they're active on every
> request.
> Being able to use feature flags outside of Sling looks nice, but ... to
> quote "someone" :) ....yagni for now

:-)

Ok, fine, I'll remove the global filter for now.

Regards
Felix

> 
> If want to have this two step setup, we should switch to lazy evaluation of
> the flags on first access.
> 
> Carsten
> -- 
> Carsten Ziegeler
> cziegeler@apache.org

Re: FeatureFlags without ResourceAccessGate

Posted by Carsten Ziegeler <cz...@apache.org>.

+1 for closing the issue


2014-01-28 Felix Meschberger <fm...@adobe.com>

> Hi
>
> Am 28.01.2014 um 11:44 schrieb Bertrand Delacretaz <bdelacretaz@apache.org
> >:
>
> > Hi,
> >
> > On Tue, Jan 28, 2014 at 11:36 AM, Felix Meschberger <fm...@adobe.com>
> wrote:
> >> ...I tracked all those changes in SLING-3148 [1]
> >> I would think we can now resolve this issue...
> >
> > Doc nitpick: I see that you have staged some docs at
> > content/documentation/the-sling-engine/featureflags.mdtext, shouldn't
> > that rather go under
> > http://sling.apache.org/documentation/bundles.html ? As you indicate,
> > this an optional feature so IMO better belongs there.
>
> Well, I think the bundles stuff is limited particularly when it comes to
> Feature Flags which involves at least two bundles: the Feature Flags bundle
> itself and the Resource Resolver bundle (support feature properties on
> resources)
>
> Regards
> Felix
>
> >
> > -Bertrand
>
>


-- 
Carsten Ziegeler
cziegeler@apache.org

Re: FeatureFlags without ResourceAccessGate

Posted by Felix Meschberger <fm...@adobe.com>.

Hi

Am 28.01.2014 um 11:44 schrieb Bertrand Delacretaz <bd...@apache.org>:

> Hi,
> 
> On Tue, Jan 28, 2014 at 11:36 AM, Felix Meschberger <fm...@adobe.com> wrote:
>> ...I tracked all those changes in SLING-3148 [1]
>> I would think we can now resolve this issue...
> 
> Doc nitpick: I see that you have staged some docs at
> content/documentation/the-sling-engine/featureflags.mdtext, shouldn't
> that rather go under
> http://sling.apache.org/documentation/bundles.html ? As you indicate,
> this an optional feature so IMO better belongs there.

Well, I think the bundles stuff is limited particularly when it comes to Feature Flags which involves at least two bundles: the Feature Flags bundle itself and the Resource Resolver bundle (support feature properties on resources)

Regards
Felix

> 
> -Bertrand

Re: FeatureFlags without ResourceAccessGate

Posted by Bertrand Delacretaz <bd...@apache.org>.

Hi,

On Tue, Jan 28, 2014 at 11:36 AM, Felix Meschberger <fm...@adobe.com> wrote:
> ...I tracked all those changes in SLING-3148 [1]
> I would think we can now resolve this issue...

Doc nitpick: I see that you have staged some docs at
content/documentation/the-sling-engine/featureflags.mdtext, shouldn't
that rather go under
http://sling.apache.org/documentation/bundles.html ? As you indicate,
this an optional feature so IMO better belongs there.

-Bertrand

Re: FeatureFlags without ResourceAccessGate

Posted by Felix Meschberger <fm...@adobe.com>.

Ok, so I finally merged back my whiteboard into trunk and also fixed a few glitches after the merge.

Now, the ResourceResolver implementation may support feature flags if the Features service is available. Yet the bundle does only have a dynamic and optional dependency on the API. So in setups where the Feature Flags bundle is not installed the ResourceResolver implementation can still be deployed and happily works without feature flag support.

I tracked all those changes in SLING-3148 [1]

I would think we can now resolve this issue.

WDYT ?

Regards
Felix

[1] https://issues.apache.org/jira/browse/SLING-3148

Am 27.01.2014 um 15:24 schrieb Carsten Ziegeler <cz...@apache.org>:

>> 
>> The global one basically just provides access to the raw request while the
>> Sling-embedded one also provides access to the SlingHttpServletRequest as
>> well as the request's ResourceResolver.
>> 
>> 
> Ah right, because you don't have the resolver in the global filter...but
> this means that all flags are tested twice if they're active on every
> request.
> Being able to use feature flags outside of Sling looks nice, but ... to
> quote "someone" :) ....yagni for now
> 
> If want to have this two step setup, we should switch to lazy evaluation of
> the flags on first access.
> 
> Carsten
> -- 
> Carsten Ziegeler
> cziegeler@apache.org

Re: FeatureFlags without ResourceAccessGate

Posted by Carsten Ziegeler <cz...@apache.org>.

>
> The global one basically just provides access to the raw request while the
> Sling-embedded one also provides access to the SlingHttpServletRequest as
> well as the request's ResourceResolver.
>
>
Ah right, because you don't have the resolver in the global filter...but
this means that all flags are tested twice if they're active on every
request.
Being able to use feature flags outside of Sling looks nice, but ... to
quote "someone" :) ....yagni for now

If want to have this two step setup, we should switch to lazy evaluation of
the flags on first access.

Carsten
-- 
Carsten Ziegeler
cziegeler@apache.org

Re: FeatureFlags without ResourceAccessGate

Posted by Felix Meschberger <fm...@adobe.com>.

Hi

Am 27.01.2014 um 14:58 schrieb Carsten Ziegeler <cz...@apache.org>:

> Thanks for the work, Felix - changes look good to me.

Thanks :-)

> 
> I'm not sure if we should register two filters, the global one should be
> enough I think.

The global one basically just provides access to the raw request while the Sling-embedded one also provides access to the SlingHttpServletRequest as well as the request's ResourceResolver.

Regards
Felix

> 
> Carsten
> 
> 
> 2014-01-27 Felix Meschberger <fm...@adobe.com>
> 
>> Hi
>> 
>> It took me a bit longer and caused me a few more changes to the
>> FeatureFlags stuff ….
>> 
>> So instead of immediately merging back to trunk, lets have another round
>> of discussions.
>> 
>> The most important changes (off the top of my mind):
>> 
>> * Support HttpServletRequest instead of requiring SlingHttpServletRequest
>> for the ClientContext and ExecutionContext. This allows using this
>> functionality outside of Sling (I hope)
>> * Add Web Console listing known features
>> * Add support for org.apache.sling.featureflags.Feature factory
>> configuration (static configuration can be overwritten with "feature"
>> request parameter)
>> * additional services registered through FeatureManager, which itself is
>> not a service any longer
>> 
>> I also added a crude page to the staging at [1]
>> 
>> WDYT ?
>> 
>> Regards
>> Felix
>> 
>> [1]
>> http://sling.staging.apache.org/documentation/the-sling-engine/featureflags.html
>> 
>> Am 17.01.2014 um 16:32 schrieb Felix Meschberger <fm...@adobe.com>:
>> 
>>> Hi
>>> 
>>> As I repeatedly said, I think the Feature Flags support should be
>> implemented without the ResourceAccessGate mechanism because it is not an
>> access control thing but a purely operational visibility thing. Also as
>> opposed to access control, feature flag enabled can and should be
>> controllable by a consumer of the API; for example by passing a request
>> parameter on the request.
>>> 
>>> Based on the existing code, I have created a prototype in my whiteboard
>> at [1]:
>>> 
>>> * On a per-resource level feature flags are set as sling:feature
>> properties of type String or String[]
>>> * Flags are checked during resource resolution in the
>> ProviderHandler.getReadableResource method
>>> * Feature services can implement ResourceDecorator such that they can
>> decorate a resource in case their feature is enabled.
>>> 
>>> I also provided diffs in the feature-flags and resourceresolver projects
>> to be able to see, what has been changed.
>>> 
>>> WDYT ?
>>> 
>>> Regards
>>> Felix
>>> 
>>> [1]
>> http://svn.apache.org/repos/asf/sling/whiteboard/fmeschbe/featureflags
>> 
>> 
> 
> 
> -- 
> Carsten Ziegeler
> cziegeler@apache.org

Re: FeatureFlags without ResourceAccessGate

Posted by Carsten Ziegeler <cz...@apache.org>.

Thanks for the work, Felix - changes look good to me.

I'm not sure if we should register two filters, the global one should be
enough I think.

Carsten


2014-01-27 Felix Meschberger <fm...@adobe.com>

> Hi
>
> It took me a bit longer and caused me a few more changes to the
> FeatureFlags stuff ….
>
> So instead of immediately merging back to trunk, lets have another round
> of discussions.
>
> The most important changes (off the top of my mind):
>
> * Support HttpServletRequest instead of requiring SlingHttpServletRequest
> for the ClientContext and ExecutionContext. This allows using this
> functionality outside of Sling (I hope)
> * Add Web Console listing known features
> * Add support for org.apache.sling.featureflags.Feature factory
> configuration (static configuration can be overwritten with "feature"
> request parameter)
> * additional services registered through FeatureManager, which itself is
> not a service any longer
>
> I also added a crude page to the staging at [1]
>
> WDYT ?
>
> Regards
> Felix
>
> [1]
> http://sling.staging.apache.org/documentation/the-sling-engine/featureflags.html
>
> Am 17.01.2014 um 16:32 schrieb Felix Meschberger <fm...@adobe.com>:
>
> > Hi
> >
> > As I repeatedly said, I think the Feature Flags support should be
> implemented without the ResourceAccessGate mechanism because it is not an
> access control thing but a purely operational visibility thing. Also as
> opposed to access control, feature flag enabled can and should be
> controllable by a consumer of the API; for example by passing a request
> parameter on the request.
> >
> > Based on the existing code, I have created a prototype in my whiteboard
> at [1]:
> >
> > * On a per-resource level feature flags are set as sling:feature
> properties of type String or String[]
> > * Flags are checked during resource resolution in the
> ProviderHandler.getReadableResource method
> > * Feature services can implement ResourceDecorator such that they can
> decorate a resource in case their feature is enabled.
> >
> > I also provided diffs in the feature-flags and resourceresolver projects
> to be able to see, what has been changed.
> >
> > WDYT ?
> >
> > Regards
> > Felix
> >
> > [1]
> http://svn.apache.org/repos/asf/sling/whiteboard/fmeschbe/featureflags
>
>


-- 
Carsten Ziegeler
cziegeler@apache.org

Re: FeatureFlags without ResourceAccessGate

Posted by Felix Meschberger <fm...@adobe.com>.

Hi

It took me a bit longer and caused me a few more changes to the FeatureFlags stuff ….

So instead of immediately merging back to trunk, lets have another round of discussions.

The most important changes (off the top of my mind):

* Support HttpServletRequest instead of requiring SlingHttpServletRequest for the ClientContext and ExecutionContext. This allows using this functionality outside of Sling (I hope)
* Add Web Console listing known features
* Add support for org.apache.sling.featureflags.Feature factory configuration (static configuration can be overwritten with "feature" request parameter)
* additional services registered through FeatureManager, which itself is not a service any longer

I also added a crude page to the staging at [1]

WDYT ?

Regards
Felix

[1] http://sling.staging.apache.org/documentation/the-sling-engine/featureflags.html

Am 17.01.2014 um 16:32 schrieb Felix Meschberger <fm...@adobe.com>:

> Hi
> 
> As I repeatedly said, I think the Feature Flags support should be implemented without the ResourceAccessGate mechanism because it is not an access control thing but a purely operational visibility thing. Also as opposed to access control, feature flag enabled can and should be controllable by a consumer of the API; for example by passing a request parameter on the request.
> 
> Based on the existing code, I have created a prototype in my whiteboard at [1]:
> 
> * On a per-resource level feature flags are set as sling:feature properties of type String or String[]
> * Flags are checked during resource resolution in the ProviderHandler.getReadableResource method
> * Feature services can implement ResourceDecorator such that they can decorate a resource in case their feature is enabled.
> 
> I also provided diffs in the feature-flags and resourceresolver projects to be able to see, what has been changed.
> 
> WDYT ?
> 
> Regards
> Felix
> 
> [1] http://svn.apache.org/repos/asf/sling/whiteboard/fmeschbe/featureflags

Re: FeatureFlags without ResourceAccessGate

Posted by Bertrand Delacretaz <bd...@apache.org>.

On Mon, Jan 20, 2014 at 4:25 AM, Carsten Ziegeler <cz...@apache.org> wrote:
> ...So I think we should really replace the current implemenation with the new
> one....

+1, I also like the whiteboard/fmeschbe/featureflags/feature-flags
implementation.

It will need tests and more debug log messages to be ready for prime
time though.

-Bertrand

Re: FeatureFlags without ResourceAccessGate

Posted by Felix Meschberger <fm...@adobe.com>.

Yes, I can — Probably tomorrow, works ?

Regards
Felix

Am 20.01.2014 um 04:25 schrieb Carsten Ziegeler <cz...@apache.org>:

> So I think we should really replace the current implemenation with the new
> one.
> 
> @Felix can you do the move please?
> 
> Carsten
> 
> 
> 2014/1/17 Justin Edelson <ju...@justinedelson.com>
> 
>> Hi Carsten,
>> FWIW, what you are describing looks like what I would expect to happen
>> - features are applied at the thread level, so any activity within
>> that thread would have the same features.
>> 
>> Regards,
>> Justin
>> 
>> On Fri, Jan 17, 2014 at 11:10 AM, Carsten Ziegeler <cz...@apache.org>
>> wrote:
>>> Hi Felix,
>>> 
>>> thanks for taking this up - as briefly discussed offline I like this new
>>> approach. It's less API and better covers our use cases.
>>> 
>>> The only thing I'm not 100% sure is the evaluation of the features within
>>> the resource resolver. It gets the current client context from the
>> features
>>> service, assuming this is set. For requests, this is the case - so that
>>> problem is solved. For internal resource resolvers this is different. As
>>> long as no request is running, an "empty" client context will be
>> returned,
>>> but within a request the context belonging to the request is returned.
>>> This sounds like the right thing, because if some request invokes a
>>> different (long running) resource resolver, both see the same state (have
>>> the same features enabled) at that point of time. However for the long
>>> running ones this might be unexpected.
>>> 
>>> I'm not sure if this poses are problem, just want to highlight this.
>>> 
>>> Other than that, +1 for moving this to trunk :)
>>> 
>>> Carsten
>>> 
>>> 
>>> 
>>> 2014/1/17 Felix Meschberger <fm...@adobe.com>
>>> 
>>>> Hi
>>>> 
>>>> As I repeatedly said, I think the Feature Flags support should be
>>>> implemented without the ResourceAccessGate mechanism because it is not
>> an
>>>> access control thing but a purely operational visibility thing. Also as
>>>> opposed to access control, feature flag enabled can and should be
>>>> controllable by a consumer of the API; for example by passing a request
>>>> parameter on the request.
>>>> 
>>>> Based on the existing code, I have created a prototype in my whiteboard
>> at
>>>> [1]:
>>>> 
>>>> * On a per-resource level feature flags are set as sling:feature
>>>> properties of type String or String[]
>>>> * Flags are checked during resource resolution in the
>>>> ProviderHandler.getReadableResource method
>>>> * Feature services can implement ResourceDecorator such that they can
>>>> decorate a resource in case their feature is enabled.
>>>> 
>>>> I also provided diffs in the feature-flags and resourceresolver projects
>>>> to be able to see, what has been changed.
>>>> 
>>>> WDYT ?
>>>> 
>>>> Regards
>>>> Felix
>>>> 
>>>> [1]
>> http://svn.apache.org/repos/asf/sling/whiteboard/fmeschbe/featureflags
>>> 
>>> 
>>> 
>>> 
>>> --
>>> Carsten Ziegeler
>>> cziegeler@apache.org
>> 
> 
> 
> 
> -- 
> Carsten Ziegeler
> cziegeler@apache.org

Re: FeatureFlags without ResourceAccessGate

Posted by Carsten Ziegeler <cz...@apache.org>.

So I think we should really replace the current implemenation with the new
one.

@Felix can you do the move please?

Carsten


2014/1/17 Justin Edelson <ju...@justinedelson.com>

> Hi Carsten,
> FWIW, what you are describing looks like what I would expect to happen
> - features are applied at the thread level, so any activity within
> that thread would have the same features.
>
> Regards,
> Justin
>
> On Fri, Jan 17, 2014 at 11:10 AM, Carsten Ziegeler <cz...@apache.org>
> wrote:
> > Hi Felix,
> >
> > thanks for taking this up - as briefly discussed offline I like this new
> > approach. It's less API and better covers our use cases.
> >
> > The only thing I'm not 100% sure is the evaluation of the features within
> > the resource resolver. It gets the current client context from the
> features
> > service, assuming this is set. For requests, this is the case - so that
> > problem is solved. For internal resource resolvers this is different. As
> > long as no request is running, an "empty" client context will be
> returned,
> > but within a request the context belonging to the request is returned.
> > This sounds like the right thing, because if some request invokes a
> > different (long running) resource resolver, both see the same state (have
> > the same features enabled) at that point of time. However for the long
> > running ones this might be unexpected.
> >
> > I'm not sure if this poses are problem, just want to highlight this.
> >
> > Other than that, +1 for moving this to trunk :)
> >
> > Carsten
> >
> >
> >
> > 2014/1/17 Felix Meschberger <fm...@adobe.com>
> >
> >> Hi
> >>
> >> As I repeatedly said, I think the Feature Flags support should be
> >> implemented without the ResourceAccessGate mechanism because it is not
> an
> >> access control thing but a purely operational visibility thing. Also as
> >> opposed to access control, feature flag enabled can and should be
> >> controllable by a consumer of the API; for example by passing a request
> >> parameter on the request.
> >>
> >> Based on the existing code, I have created a prototype in my whiteboard
> at
> >> [1]:
> >>
> >> * On a per-resource level feature flags are set as sling:feature
> >> properties of type String or String[]
> >> * Flags are checked during resource resolution in the
> >> ProviderHandler.getReadableResource method
> >> * Feature services can implement ResourceDecorator such that they can
> >> decorate a resource in case their feature is enabled.
> >>
> >> I also provided diffs in the feature-flags and resourceresolver projects
> >> to be able to see, what has been changed.
> >>
> >> WDYT ?
> >>
> >> Regards
> >> Felix
> >>
> >> [1]
> http://svn.apache.org/repos/asf/sling/whiteboard/fmeschbe/featureflags
> >
> >
> >
> >
> > --
> > Carsten Ziegeler
> > cziegeler@apache.org
>



-- 
Carsten Ziegeler
cziegeler@apache.org

Re: FeatureFlags without ResourceAccessGate

Posted by Justin Edelson <ju...@justinedelson.com>.

Hi Carsten,
FWIW, what you are describing looks like what I would expect to happen
- features are applied at the thread level, so any activity within
that thread would have the same features.

Regards,
Justin

On Fri, Jan 17, 2014 at 11:10 AM, Carsten Ziegeler <cz...@apache.org> wrote:
> Hi Felix,
>
> thanks for taking this up - as briefly discussed offline I like this new
> approach. It's less API and better covers our use cases.
>
> The only thing I'm not 100% sure is the evaluation of the features within
> the resource resolver. It gets the current client context from the features
> service, assuming this is set. For requests, this is the case - so that
> problem is solved. For internal resource resolvers this is different. As
> long as no request is running, an "empty" client context will be returned,
> but within a request the context belonging to the request is returned.
> This sounds like the right thing, because if some request invokes a
> different (long running) resource resolver, both see the same state (have
> the same features enabled) at that point of time. However for the long
> running ones this might be unexpected.
>
> I'm not sure if this poses are problem, just want to highlight this.
>
> Other than that, +1 for moving this to trunk :)
>
> Carsten
>
>
>
> 2014/1/17 Felix Meschberger <fm...@adobe.com>
>
>> Hi
>>
>> As I repeatedly said, I think the Feature Flags support should be
>> implemented without the ResourceAccessGate mechanism because it is not an
>> access control thing but a purely operational visibility thing. Also as
>> opposed to access control, feature flag enabled can and should be
>> controllable by a consumer of the API; for example by passing a request
>> parameter on the request.
>>
>> Based on the existing code, I have created a prototype in my whiteboard at
>> [1]:
>>
>> * On a per-resource level feature flags are set as sling:feature
>> properties of type String or String[]
>> * Flags are checked during resource resolution in the
>> ProviderHandler.getReadableResource method
>> * Feature services can implement ResourceDecorator such that they can
>> decorate a resource in case their feature is enabled.
>>
>> I also provided diffs in the feature-flags and resourceresolver projects
>> to be able to see, what has been changed.
>>
>> WDYT ?
>>
>> Regards
>> Felix
>>
>> [1] http://svn.apache.org/repos/asf/sling/whiteboard/fmeschbe/featureflags
>
>
>
>
> --
> Carsten Ziegeler
> cziegeler@apache.org

Re: FeatureFlags without ResourceAccessGate

Posted by Carsten Ziegeler <cz...@apache.org>.

Hi Felix,

thanks for taking this up - as briefly discussed offline I like this new
approach. It's less API and better covers our use cases.

The only thing I'm not 100% sure is the evaluation of the features within
the resource resolver. It gets the current client context from the features
service, assuming this is set. For requests, this is the case - so that
problem is solved. For internal resource resolvers this is different. As
long as no request is running, an "empty" client context will be returned,
but within a request the context belonging to the request is returned.
This sounds like the right thing, because if some request invokes a
different (long running) resource resolver, both see the same state (have
the same features enabled) at that point of time. However for the long
running ones this might be unexpected.

I'm not sure if this poses are problem, just want to highlight this.

Other than that, +1 for moving this to trunk :)

Carsten



2014/1/17 Felix Meschberger <fm...@adobe.com>

> Hi
>
> As I repeatedly said, I think the Feature Flags support should be
> implemented without the ResourceAccessGate mechanism because it is not an
> access control thing but a purely operational visibility thing. Also as
> opposed to access control, feature flag enabled can and should be
> controllable by a consumer of the API; for example by passing a request
> parameter on the request.
>
> Based on the existing code, I have created a prototype in my whiteboard at
> [1]:
>
> * On a per-resource level feature flags are set as sling:feature
> properties of type String or String[]
> * Flags are checked during resource resolution in the
> ProviderHandler.getReadableResource method
> * Feature services can implement ResourceDecorator such that they can
> decorate a resource in case their feature is enabled.
>
> I also provided diffs in the feature-flags and resourceresolver projects
> to be able to see, what has been changed.
>
> WDYT ?
>
> Regards
> Felix
>
> [1] http://svn.apache.org/repos/asf/sling/whiteboard/fmeschbe/featureflags




-- 
Carsten Ziegeler
cziegeler@apache.org