users@javaee-spec.java.net

[javaee-spec users] Re: [jsr366-experts] Re: Common services back to their specifications ?

From: Bill Shannon <bill.shannon_at_oracle.com>
Date: Fri, 16 Jan 2015 13:47:12 -0800

arjan tijms wrote on 01/16/15 09:46:
> Hi,
>
> On Thu, Jan 15, 2015 at 1:55 AM, Bill Shannon <bill.shannon_at_oracle.com> wrote:
>
>> If we could build @Asynchronous support on interceptors, that would be
>> great.
>
> I gave it a quick shot (see
> http://lists.jboss.org/pipermail/cdi-dev/2015-January/006065.html),
> but it doesn't seem to be entirely trivial.

Yes, interesting. Thanks for trying it out! It seems that we're
pretty close to being able to do this!

>> If we need to enhance interceptors to make that possible, let's
>> consider that.
>
> I've asked this question on the CDI list as well. Maybe it's enough to
> just have the option on the InvocationContext to set it in async mode.
> E.g.
>
> @AroundInvoke
> public Object submitAsync(InvocationContext ctx) {
> ctx.startAsync();
> // schedule some work on pool with ctx as param
> }
>
> This wouldn't need to do much, e.g. just like in Servlet it would not
> need to create threads or submit work to pools. Instead, it would
> simply need to allow that InvocationContext instance to be used in
> other threads.
>
> With such support an other spec can probably do the actual
> implementation of @Asynchronous easily.

If you clone the InvocationContext and pass the clone to the async work,
does that work? Although it's not clear the spec requires that that *should*
work, so something like you suggest above may still be necessary.