On 01/12/11 15:01, Marek Potociar wrote:
>
>
> On 11/30/2011 04:12 PM, Sergey Beryozkin wrote:
>> On 30/11/11 13:20, Bill Burke wrote:
>>>
>>>
>>> On 11/30/11 5:52 AM, Marek Potociar wrote:
>>>>
>>>> public interface NextAction { }
>>>>
>>>> IMO it should be defined as an inner interface of FilterContext. We
>>>> can add some methods if we find it useful. Otherwise
>>>> it should be up to the implementation how to implement the interface
>>>> and what methods should be internally provided.
>>>
>>> Yuck. -1 on a special interface. What about my proposal with filter
>>> returning void, and FilterContext having a state or a set of boolean
>>> methods that describe the state:
>>>
>>> void preFilter(FilterContext ctx) {
>>> context.stop();
>>> }
>>>
>>> ctx.isStopped();
>>>
>> +1 to having 'void' only for this filter api option. I'd preferOn 01/12/11 15:01, Marek Potociar wrote:
>
>
> On 11/30/2011 04:12 PM, Sergey Beryozkin wrote:
>> On 30/11/11 13:20, Bill Burke wrote:
>>>
>>>
>>> On 11/30/11 5:52 AM, Marek Potociar wrote:
>>>>
>>>> public interface NextAction { }
>>>>
>>>> IMO it should be defined as an inner interface of FilterContext. We
>>>> can add some methods if we find it useful. Otherwise
>>>> it should be up to the implementation how to implement the interface
>>>> and what methods should be internally provided.
>>>
>>> Yuck. -1 on a special interface. What about my proposal with filter
>>> returning void, and FilterContext having a state or a set of boolean
>>> methods that describe the state:
>>>
>>> void preFilter(FilterContext ctx) {
>>> context.stop();
>>> }
>>>
>>> ctx.isStopped();
>>>
>> +1 to having 'void' only for this filter api option. I'd prefer
>> FilterContext having no stop/continue/suspend at all.
>> FilterContext.setResponse is a good enough way to indicate to the runtime that this has provided a response of its own
>> or not
>
> IMHO, FilterContext.setResponse(...) is a very cryptic way of saying that the request filter chain execution is stopped
> and the response processing should be resumed. It's certainly not immediately clear that this operation breaks the
> filter chain.
>
What is so cryptic about it ?
I'm a filter developer and I know that my filter may be able to provide
a Response or update the current request properties. If the Response is
available then I set and I'm done; As a filter developer I'm not
thinking about chains which needs to be stopped or resumed elsewhere, I
just think that this is a Response, let the runtime worry about making
it available to the consumer. Is it really cryptic ? IMHO it certainly
less than also returning Next
> Marek
>
>>
>> Cheers, Sergey
>>
>>> BTW, We're starting to implement the spec next week. I'll probably have
>>> a lot more comments when we start playing with things.
>>>
>>>
>>
>>
>> FilterContext having no stop/continue/suspend at all.
>> FilterContext.setResponse is a good enough way to indicate to the runtime that this has provided a response of its own
>> or not
>
> IMHO, FilterContext.setResponse(...) is a very cryptic way of saying that the request filter chain execution is stopped
> and the response processing should be resumed. It's certainly not immediately clear that this operation breaks the
> filter chain.
>
What is so cryptic about it ?
I'm a filter developer and I know that my filter may be able to provide
a Response or update the current request properties. If the Response is
available then I set and I'm done; As a filter developer I'm not
thinking about chains which needs to be stopped or resumed elsewhere, I
just think that this is a Response, let the runtime worry about making
it available to the consumer. Is it really cryptic ?
IMHO it certainly less than also returning NextAction alonside setting
the Response on the filter chain - and getting this state of mind that
my filter needs to tell the runtime what it should do next.
Sergey
> Marek
>
>>
>> Cheers, Sergey
>>
>>> BTW, We're starting to implement the spec next week. I'll probably have
>>> a lot more comments when we start playing with things.
>>>
>>>
>>
>>