[
https://issues.apache.org/jira/browse/SLING-3350?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13886374#comment-13886374
]
Felix Meschberger commented on SLING-3350:
------------------------------------------
Applied a modified version of the patch in Rev. 1562712:
* ClientContext interface is removed
* Feature flags are lazily evaluated and cached in the ExecutionContext
* Removed ResourceDecorator
* Merged Filter, Servlet, and Features service implementations into
FeatureManager
* Only one filter registered; ResourceResolver retrieved from request attribute
* Simplified and clarified Features API
I have removed the ResourceDecorator functionality because it can be
implemented outside of the core Feature Flag implementation. Actually, I think
most Feature service will not be ResourceDecorator at all. If an application
wants to decorate resources depending on some Feature flag that application can
still implement its own decorator asking the Features service for the
respective feature flag value.
> Simplify Feature Flags API
> --------------------------
>
> Key: SLING-3350
> URL: https://issues.apache.org/jira/browse/SLING-3350
> Project: Sling
> Issue Type: Improvement
> Components: Extensions
> Reporter: Felix Meschberger
> Assignee: Felix Meschberger
> Fix For: Feature Flags 1.0.0
>
> Attachments: SLING-3350.patch
>
>
> The Feature Flags API currently is quite complex involving a helper object
> making query for FeatureFlag status quite complex. Also, setting the current
> context is clumsy with (currently) two filters.
> I propose a few changes:
> (a) Remove ClientContext object. Checking for feature enablement should be as
> simple as just calling "Features.isEnabled(featureName)". Currently the
> curent ClientContext has to be retrieved and then the isEnabled method being
> called there.
> (b) Feature flag values are egerly evaluated. This should be done on demand
> making the context setup much quicker and light-weight. For added performance
> the evaluation results can still be cached.
> (c) The duplicate filter can be removed by code directly grabbing the
> ResourceResolver from the request attribute just like the SlingMainServlet
> does (thanks CarstenZ for the hint).
> (d) We don't currently need the explicit "context" management because the
> servlet filter does that directly using internal API.
> (e) I wonder, whether we need all these feature accessors in the Features
> service, some look like convenience methods, particularly the one of
> getFeatureNames and getFeatures.
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
