Hi Simo Are you sure you updated to the latest trunk build of the ResourceResolver bundle ?
When debugging you should see the (new) ResourceResolverContext.applyFeatures method be called from ProviderHandler.getReadableResource. If that is not the case you ResourceResolver bundle is outdated. Regards Felix Am 29.01.2014 um 14:16 schrieb Simone Tripodi <[email protected]>: > Hi Felix! > > thanks a lot for following up - unfortunately, once updated my local copy > of Sling, reinstalled everything and re-set up my environment, I noticed > that even if I hardcode a Feature to return `true`, the Resource would be > hidden anyway... > > I guess that Feature#isEnabled(ExecutionContext) method is invoked but not > correctly evaluated... do you have an idea why it could happen? > > TIA, Alles Gute! > -Simo > > > http://people.apache.org/~simonetripodi/ > http://twitter.com/simonetripodi > > > On Wed, Jan 29, 2014 at 1:40 PM, Carsten Ziegeler <[email protected]>wrote: > >> 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] >>
