(After two weeks of vacation and one week of all-day meetings, I'm just
starting to catch up with these expert group conversations...)
arjan tijms wrote on 12/19/14 16:03:
> Hi,
>
> On Fri, Dec 19, 2014 at 9:15 PM, Bill Shannon <bill.shannon_at_oracle.com> wrote:
>> Why wouldn't it be sufficient for CDI to define its own @Asynchronous
>> annotation and have everything else that needed asynchronous method
>> invocation depend on CDI?
>
> That's certainly a valid question, but the answer I think depends on
> what we want CDI to be.
>
> Is CDI a base bean model with a small set of core supporting services
> for injection and lifecycle management, or should CDI increasingly
> adopt more enterprise features such as concurrency, security,
> transactions, (job) scheduling, etc?
>
> Should most other specs build on CDI, or should CDI build on most other specs?
In general, other specs should build on CDI. With the CDI 2.0 plan to
split CDI into parts, that should make it easier for other specs to build
on it.
> Currently both views seem to be in place. As Antonio mentioned, JTA
> choose to implement declarative transactions itself, but based on CDI.
> If I remember correctly it was a very explicit decision to not put
> this into CDI. JSF also very explicitly choose to implement its
> @ViewScoped and @FlowScoped itself but based on CDI, instead of asking
> CDI to implement something like that.
>
> But at the same time a couple of producers for artifacts originating
> from Servlet, JTA and the security system were put into CDI.
Some of these may have been mistakes. :-)
> If @Asynchronous is going to be defined by CDI, then I feel this is
> not just about that annotation and some supporting code being there or
> not, but also about supporting the idea that CDI should build on other
> specs. Is this indeed what we want?
That's an interesting question. If CDI provided @Asynchronous support,
and that support was built on the thread management in the Concurrency
spec, that moves CDI further up the stack. Maybe concurrency and
injection are so fundamental that that would be acceptable. And since
that's only an implementation dependency instead of an API dependency,
maybe it's not so bad. But it would make it more complicated.
If there were a way to build @Asynchronous support without building it
into CDI itself, that would avoid the problem. Could @Asynchronous
support be built using CDI interceptors, like we did for transactions
and hope to do for security?