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.
-- 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/