jsr339-experts@jax-rs-spec.java.net

[jsr339-experts] Re: [jax-rs-spec users] Re: Re: Re: Remove @ManagedAsync Re: Re: Re: Latest async API changes

From: Sergey Beryozkin <sberyozkin_at_talend.com>
Date: Tue, 25 Sep 2012 17:44:06 +0100

On 25/09/12 17:22, Marek Potociar wrote:
>
> On Sep 24, 2012, at 10:30 AM, Sergey Beryozkin<sberyozkin_at_talend.com> wrote:
>
>> On 24/09/12 18:25, Bill Burke wrote:
>>>
>>>
>>> On 9/24/2012 1:16 PM, Sergey Beryozkin wrote:
>>>> Hi
>>>> On 15/08/12 18:02, Marek Potociar wrote:
>>>>> Experts,
>>>>>
>>>>> While I disagree with most of what Bill is objecting to, I have not
>>>>> received any other real support for either side from you. So, since I do
>>>>> not feel strongly about having these features in JAX-RS now, to move out
>>>>> of this deadlock situation I have updated the async API proposal as
>>>>> follows:
>>>>>
>>>>> * removed all properties from @Suspended
>>>>> o the injected AsyncResponse is suspended indefinitely by default
>>>>> which may be changed using its programmatic API
>>>>> * removed ConnectionCallback from JAX-RS API
>>>>> * removed @ManagedAsync from JAX-RS API
>>>>> * added varargs versions of AsyncResponse.register() methods.
>>>>> * updated examples and javadoc accordingly
>>>>>
>>>>
>>>> At the moment, do you see @Suspended (as a parameter-level annotation)
>>>> redundant ? It does seem to me it is:
>>>>
>>>> @GET
>>>> public String get(@Suspended AsyncResponse) {}
>>>>
>>>
>>> Redundant, but, similarly we don't need @Context either.
>>>
>> OK
>>>> I mean, the runtime can decide what to do based on the fact that a given
>>>> method parameter type is AsyncResponse ?
>>>>
>>>> The other question, what about the following style:
>>>>
>>>> @GET
>>>> @Suspended
>>>> public String get() {}
>>>>
>>>
>>> This looks like @ManagedAsync and I thought we closed the book on that...
>>>
>> Right :-). I'm sorry, only now starting to look into it... Well, we can of course do that in CXF only, would appreciate a short description why, there was a long discussion which I spotted while looking for the last message in the thread, difficult to get why it was dropped :-)
>
> In short: @ManagedAsync was dropped because Bill did not want it there and nobody supported my proposal to keep it there. Since I did not feel strongly about that, I did not fight for the feature. FWIW, we do provide @ManagedAsync support in the upcoming Jersey 2.0.
>

We'll do the same in CXF - I like this style

> As for Bill's reasons of why to not have the annotation in the API, I'll let him explain :)
>
> Marek
>
> P.S. I would not support change in the style. I would only support @ManagedAsync as a complementary annotation the existing to @Suspended parameter-level annotation. Also I am ready to strongly fight against any more changes in the style of the async API. We had the discussion several times already. The API has settled down, the time for that design-level discussion is gone and we should move on. (Unless there is a really major issue with the API, of course).

Sure, agreed. I thought about 'relaxing' @Suspended (for it to be
attachable to methods) as opposed to actually affecting the
'AsyncResponse' style. I won't have issues with having ManagedAsync
added instead. Guess it can be reviewed in 2.1 ? I honestly do not see
what is that bad about having simple suspended invocation cases managed
transparently - but I can live without it in the spec itself for now

Sergey

>
>> The style looks less-intrusive for me, thought it would do nice as an alternative (but not as the substitution to AsyncResponse)
>>
>> Sergey
>