CDI integration

Guillermo González de Agüero


Time is quickly running out, and I guess what the plans are regarding CDI alignment. There's an open issue [1] labeled as "2.1-candidate" but it seems no work has been done on that yet.

Given the time and resource limits the EG has, I propose to simply add a note to the spec saying that "when running on a Java EE Application Server/when CDI is available, resources and providers MUST be available for CDI extensions to process it, just like if had a CDI bean defining annotation", e.g.: providers and resources are discovered by the CDI runtime like any other bean, but *they don't need to be treated as beans*. That basically ressembled the behaviour offered by trimmed archives on CDI 2.0 [2].

What we gain with that? Users could easily create an extension to make all the resources @RequestScoped, while maintaining the spec clean (further integration would need more discussion). At the moment it's not possible to do that with CDI [3] and you have to mark all your classes as @Dependent (a practice that is not so uncommon [4]) or mark CDI bean discovery "all"/"trimmed".

How do you see it? Do you think it's viable at this time?

Join to automatically receive all group messages.