Marek,
I had some time to think about it and still dislike this style you
propose, but I can also see why some people can dislike using 'null'.
Personally I'd go either for the 'returning Response' style or having a
void with the optional Response being set on the context as per the
Bill's email.
before doing a complete analysis, I'd like to see how your proposed
interface to be returned from filters may look like, can you prototype
it here, I believe you said it's not going to be an enum ?
Cheers, Sergey
On 29/11/11 17:25, Marek Potociar wrote:
>
>
> On 11/29/2011 05:58 PM, Sergey Beryozkin wrote:
>> On 29/11/11 16:27, Marek Potociar wrote:
>>>
>>>
>>> On 11/29/2011 04:50 PM, Sergey Beryozkin wrote:
>>>> On 29/11/11 15:47, Sergey Beryozkin wrote:
>>>>> On 29/11/11 15:39, Marek Potociar wrote:
>>>>>> That's another viable option IMO.
>>>>>>
>>>>>> Although I still prefer the filter to actively return the continuation
>>>>>> as it's more in line with the simpler, functional
>>>>>> programming style (like it or not, JAX-RS filter IS a function) as
>>>>>> well as because I find it personally more robust,
>>>>>> readable and less error prone (as it eliminates potential
>>>>>> illegal/unintended context states) e.g.:
>>>>>>
>>>>>> public void preFilter(ctx) {
>>>>>>
>>>>>> if (stop) {
>>>>>> context.stop(response);
>>>>>> // bug - forgot the return
>>>>>> }
>>>>>>
>>>>>> context.continue(request);
>>>>>> // what now? is the above going to produce an exception or just continue?
>>>>>> }
>>>>>
>>>>> The whole idea about using an input parameter to indicate a course of
>>>>> action is just a broken, broken, broken idea, apologies for getting into
>>>>> the loop here.
>>>>
>>>> Sorry Marek, I meant "asking a JAX-RS implementation via an input parameter to indicate to this very implementation what
>>>> it should after the filter returns" is not a best idea IMHO
>>>
>>> May I ask why do you think that? What I'm proposing is a form of CPS[1]. What's wrong with that?
>>
>> I'd like to suggest that we take a step back and see again what is is that filters may need to do.
>> IMHO, in 95% (or close to it) users will want to use filters to update the existing request and let the request to
>> continue or block the request.
>> So lets chat again and see first what is the simplest option toward addressing those 2 major cases. For those 2 cases,
>> [1] does seem a bit too much to me.
>
> Really? Returning an opaque interface is too much while returning null Response is ok? :)
>
>>
>> Next the only other case I can see us needing to address in the future versions of the spec is support for the suspended
>> invocations.
>> I'd do
>>
>> // this sets some internal status or throws a dedicated RuntimeException
>> context.getContinuation("mycontinuation").suspend();
>> return null;
>>
>
> I don't like that for any future continuation enhancements (like this one) we would propose a completely different
> mechanism for handling the continuation. Why cannot we simply return the continuation? It's the most natural thing to do
> in a non-wrapping filter.
>
>> or something similar...
>> Lets do the comparison again for addressing the first 2 approaches and then see what it can take to get a suspended
>> invocation supported and if the group gets behind the new proposed approach then I will be the first to promote it
>
> I'm lost again. What are the "first 2 approaches"? Why don't you just do any comparison you want right away?
>
> Marek
>
>>
>> Sergey
>>
>>>
>>> Marek
>>>
>>> [1] http://en.wikipedia.org/wiki/Continuation-passing_style
>>>
>>>>
>>>> Sorry if I'm losing it a bit :-), may be I'm just missing the point
>>>> Thanks
>>>>
>>>>
>>>>> Here I am writing my JAX-RS 2 impl:
>>>>>
>>>>> FilterContextImpl.stop( return FilterAction.STOP ):
>>>>>
>>>>> FilterAction action = filter.preFilter()
>>>>> if (action == FilterAction.STOP {
>>>>> // sucks, I already returned FilterAction.STOP from my filter impl
>>>>> }
>>>>>
>>>>> how about this piece:
>>>>>
>>>>> > public void preFilter(ctx) {
>>>>> >
>>>>> > if (stop) {
>>>>> > context.stop(response);
>>>>> // ooops
>>>>> > return FilterAction.CONTINUE
>>>>> > }
>>>>> >
>>>>> > }
>>>>>
>>>>> I'm just seeing a bad dream I guess
>>>>> Sergey
>>>>>
>>>>>
>>>>>>
>>>>>> Marek
>>>>>>
>>>>>>
>>>>>> On 11/29/2011 04:22 PM, Bill Burke wrote:
>>>>>>>
>>>>>>>
>>>>>>> On 11/29/11 8:43 AM, Marek Potociar wrote:
>>>>>>>> public class MyFilter implements RequestFilter {
>>>>>>>>
>>>>>>>> public FilterAction preFilter(FilterContext context) {
>>>>>>>> // ... do some request processing
>>>>>>>> if (stopProcessing) {
>>>>>>>> return context.stop(response);
>>>>>>>> }
>>>>>>>>
>>>>>>>> return context.continue(request);
>>>>>>>> }
>>>>>>>> }
>>>>>>>>
>>>>>>>
>>>>>>> Why do you need FilterAction if these methods would be available on
>>>>>>> FilterContext?
>>>>>>>
>>>>>>>
>>>>>>> it could be just:
>>>>>>>
>>>>>>> public void preFilter(ctx) {
>>>>>>>
>>>>>>> if (stop) {
>>>>>>> context.stop(response);
>>>>>>> return;
>>>>>>> }
>>>>>>>
>>>>>>> context.continue(request);
>>>>>>>
>>>>>>> }
>>>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>
>>
--
Sergey Beryozkin
Talend Community Coders
http://coders.talend.com/
Blog: http://sberyozkin.blogspot.com