What about just having the global filter and using the same mechanism as
the Sling Main Servlet does?
// get ResourceResolver (set by AuthenticationSupport)
Object resolverObject =
request.getAttribute(AuthenticationSupport.REQUEST_ATTRIBUTE_RESOLVER);
resolver = (resolverObject instanceof ResourceResolver)
? (ResourceResolver) resolverObject
: null;
Carsten
2014-01-29 Carsten Ziegeler <[email protected]>
> 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]
>
--
Carsten Ziegeler
[email protected]
