On 30/11/11 10:52, Marek Potociar wrote:
>
>
> On 11/30/2011 10:54 AM, Sergey Beryozkin wrote:
>> 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.
>
> I have already acknowledged that Bill's proposal is a viable option, although I have my objections to it (mutable, more
> error-prone, code does not feel like a filter function etc. - see my other emails). As for returning a (null) Response
> from a request filter, I was thinking more about it and I'm afraid I cannot support such solution. I find it illogical
> and impossible to extend consistently.
>
This just a bit of over-reaction to say the least
>> 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 ?
>
> As I wrote, my initial thought would be to provide an opaque interface. By that I mean method-less interface:
>
> 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.
> This interface is not meant to be cross-implementation compatible, e.g. NextAction instance created by RestEasy runtime
> will not be understood by Jersey runtime (which is the only drawback of the solution compared to Bill's proposal that I
> can see, but I consider it really as purely theoretical and insignificant issue - adding some getter methods to the
> interface might even solve the issue, but I really don't see a valid real-life use case).
I think I disagree with this proposal even more now and the reason it
has the 'premature preparation for the extensions filters may or may not
need' written all over it. However, I'm going to come up with some
analysis asap.
Thanks, Sergey
>
> Marek
>
>>
>> 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