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);
>>>>>>
>>>>>> }
>>>>>>
>>>>
>>>>
>>>
>>>
>
>