Hi I think we have an API problem ;-)
One reason for eager resolution would probably be to have a ClientContext.getEnabledFeatures() method. I somehow fail to understand why we have this method in the first place. So if we remove getEnabledFeatures() from ClientContext we are left with isEnabled(String). A single method makes the a dubious case for an interface and we might rather have this on the Features service itself. This drops ClientContext from the public API. Then, adding Features.isEnabled(String), we need to have contextual information there. But this could be managed internally by the Features service. The filters would then just call (a new method) setRequest(HttpServletRequest) and dropRequest(HttpServletRequest) which just causes the internal contextual information to be updated. Results of calling Features.isEnabled(String) could be cached in the internal contextual information and be dropped on calls to setRequest and dropRequest WDYT ? Regards Felix Am 29.01.2014 um 13:40 schrieb 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]
