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