Hi Santiago
On 18/11/11 15:14, Santiago Pericas-Geertsen wrote:
> Hi Sergey,
>
> It's an interesting observation. However, I think there may be use cases in which you want to stop the chain _without_ producing a response.
>
> Suppose an app has 2 authentication filters (e.g. for different authentication mechanisms it supports): if the first filter authenticates the user, then there's no need to run the next filter but there's also no response to be set. This is why I think there's value in separating continuations from responses.
So FilterAction.STOP stops processing the current filter chain, right ?
How the actual request can be blocked then ?
Cheers, Sergey
>
> -- Santiago
>
>> In order to block a request and provide a response, filters need to return FilterAction.STOP and set a Response on FilterContext.
>>
>> What do you think of dropping FilterAction altogether and removing FilterContext.setResponse and have filters a Response return type.
>> If it's not null - it's a blocking action with Response being available, if it is null - the request is good to continue.
>>
>> FilterAction is kind of ok, but I'm not quite comfortable with what seems like a workaround to do with the possible need to effectively return two parameters (action status and a possible blocking Response value) and as such FilterAction seems redundant; without it FilterContext gets simpler, no space for ambiguities like FilterAction.NEXT with FilterContext.getResponse() returning a non-null value
>>
>> Thoughts ?
>> Sergey
>>
>>
>> --
>> Sergey Beryozkin
>>
>> http://sberyozkin.blogspot.com
>>
>> Talend Community Coders
>> http://coders.talend.com/
>
--
Sergey Beryozkin
http://sberyozkin.blogspot.com
Talend Community Coders
http://coders.talend.com/