This doesn't solve the problem - see previous mails as the resource resolver is not available when it should be. I like the ClientContext approach as this gives you context information, especially which features are enabled - which e.g. might be interesting for debugging etc.
Carsten 2014-01-29 Felix Meschberger <[email protected]> > 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] > > -- Carsten Ziegeler [email protected]
