Hi Bill
On 26/09/12 13:13, Bill Burke wrote:
>
>
> On 9/25/2012 12:22 PM, Marek Potociar wrote:
>> 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
>>
>
> Unless Sergey wants my reasoning why it shouldn't be there, I'd rather
> not start an argument again :)
LOL, I'm always eager to listen :-).
As I said, I'm not planning to challenge the existing AsyncResponse
style, I was not ready to do it at the time and now it is too late
anyway; I think it's a useful style to have to support, for users who
know what they do.
Here are few minor issues I'm seeing, as I'm trying to refactor an
existing CXF test to use AsyncResponse:
- this style requires 'void' response type, it does not read good when
we handle GETs.
- awkward to handle at the subresource level - one has to propagate
AsyncResponse down to the subresource - which I guess does not go well
with the idea of ResourceContext
The above are not real issues - AsyncResponse does give us the flexibility.
I think ManagedAsync style can complement the AsyncResponse one for
'simple' not too sophisticated suspended invocation cases, when having a
JAX-RS style of coding is also important (aka, no explicit dealing with
managing the invocation via AsyncResponse).
I will do the home work and review the whole thread...
Sergey
>