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: Marek Potociar <marek.potociar_at_oracle.com>
Date: Tue, 25 Sep 2012 09:22:00 -0700

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.

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

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