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
