I just realized that this doesn't help us - we need to set the resource resolver to the ExecutionContext before the features are evaluated and even with a lazy check for enabled features, the resource resolver would not be available for the initial resource lookup as this is still done before the request filter is run.
So I think we should not base this on a Sling request filter. Carsten 2014-01-29 Carsten Ziegeler <[email protected]> > I think we should avoid the double evaluation - especially as this might > result in interesting situations, a feature is enabled in the global filter > by disabled in the per request filter. > Apart from enabling a feature based on request information, features might > be enabled based on user information - which can only get once the resource > resolver is enabled - so it makes sense to have this in the > ExecutionContext. > > I guess lazy evaluation is the only way to solve this - the other would be > to not use filters and add the code to the sling main servlet, something > which I would try avoid :) > > If you want to, I can give the lazy evaluation a try? > > Carsten > > > 2014-01-29 Felix Meschberger <[email protected]> > > Hi >> >> Thanks for reporting. This is actually a consequence of me removing the >> global ClientContext filter yesterday. I have fixed it now in trunk (as >> well as another bug causing negative features to not be evaluated >> correctly). >> >> Why is the global filter needed ? Because the initial resource resolution >> takes place *before* the Sling Filters are called. Thus, the only way to >> setup the "global" per-request client context properly before resource >> resolver kicks in is to have the global filter set. >> >> Hence we have two filters again. >> >> So maybe, we should start thinking about whether eager evaluation of the >> flags might become too expensive or how we can actually improve in other >> ways ? >> >> Regards >> Felix >> >> Am 29.01.2014 um 11:03 schrieb Simone Tripodi <[email protected]>: >> >> > Hi all mates, >> > >> > I am using the new FeatureFlags APIs to implement my own Flags rules >> but I >> > noticed that Features are never evaluated, I mean that I cannot track >> > any Feature#isEnabled(ExecutionContext) method invocation. >> > >> > It is enough for a resource having a sling:features property with a >> valid >> > service name to be disabled -and dropping it re-enables the Resource- it >> > doesn't matter which boolean value the >> > method Feature#isEnabled(ExecutionContext) returns, it is not hit >> neither >> > evaluated. >> > >> > How can I provide you a valid IT to demonstrate it? >> > >> > TIA, all the best! >> > -Simo >> > >> > http://people.apache.org/~simonetripodi/ >> > http://twitter.com/simonetripodi >> >> > > > -- > Carsten Ziegeler > [email protected] > -- Carsten Ziegeler [email protected]
