On 6/18/12 5:14 PM, Marek Potociar wrote:
>
> On Jun 18, 2012, at 5:16 PM, Bill Burke wrote:
>
>> @Suspend is currently a pretty useless annotation.
>>
>> @Suspend(timeout=12345)
>> public void get(@Context ExecutionContext ctx);
>>
>> Really isn't much different than:
>>
>>
>> public void get(@Context ExecutionContext ctx)
>> {
>> ctx.suspend(12345);
>> }
>>
>> How about allowing @Suspend to inject an ExecutionContext?
>>
>> public void get(@Suspend ExecutionContext ctx);
>>
>> At least in this case, you're saving the typing of @Context.
>
> Interesting idea. I wonder what would you do about field injection (typical for external event async scenarios)? I don't like mixing @Context and @Suspend for the two cases. Also, it is weird that I would not be able to suspend a method via annotation without injecting the context at the same time. Or would I? But in that case I would object that mixing concerns of "suspend" and "inject" is confusing.
>
Can't really have a @Suspend without an ExecutionContext. I'd say
remove @Suspend. I don't think it buys any extra usability.
> On a related note, I plan to work on extending the async API a bit. I heard rants from external users on Tweeter that we are missing a concept of callback that would be able to handle events like "connection closed by client", "timeout" etc. Admittedly those rants are quite true. So the @Suspend annotation should be convenient for declarative method suspend configuration beyond current timeout capabilities.
>
Sounds great. I really like the idea of those callbacks and have had a
need for them in the past for the restful messaging service we wrote.
BTW, I don't think the servlet spec has specific callbacks for those events.
Bill
--
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com