On Jun 19, 2012, at 12:02 AM, Bill Burke wrote:
>
>
> 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.
I disagree - consider this example:
@Path("root)
class MyResource {
@Context ExecutionContext ctx;
@Suspend @GET @Path("a")
public void getA() {...} // waits for external event
@Suspend @GET @Path("b")
public void getB() {...} // waits for external event
@Suspend @GET @Path("c")
public void getC() {...} // waits for external event
@POST
public void post() {...} // resumes some suspended context(s)
@PUT
public void put() {...} // resumes some suspended context(s)
@DELETE
public void delete() {...} // resumes some suspended context(s)
}
Why should I be forced to inject the context into each get method or programmatically invoke ctx.suspend()? Also see bellow the plans for @Suspend extension.
>> 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.
Yep, servlets will be a bit of a challenge. Yet we should be able to implement the support without the support in Servlet API. In any case, that's a good point - I may want to talk to Rajiv about their potential plans for adding the callback support in Servlet 3.1. I'll do that s soon as we have a better idea of what our API should look like.
Marek
>
> Bill
>
> --
> Bill Burke
> JBoss, a division of Red Hat
> http://bill.burkecentral.com
>
>