[cdi-dev] Feedback from Devoxx
arjan.tijms at gmail.com
Mon Nov 17 10:28:08 EST 2014
On Mon, Nov 17, 2014 at 2:57 PM, Antoine Sabot-Durand
<antoine at sabot-durand.net> wrote:
> Just to give you a small feedback of my Devoxx week regarding CDI and CDI 2.0 (for the rest, what happens in Devoxx stays in Devoxx ;) )
> 1) Great expectations:
> [...] (the question of total EJB replacement came more than once)
I heard this a number of times as well, both before and during Devoxx.
A great number of issues for decoupling EJB features (meaning,
providing CDI based replacements) have already been created as spec
* Decoupling the @Schedule annotation from the EJB component model (EJB_SPEC-1)
* Decoupling the TimerService API from the EJB component model (EJB_SPEC-2)
* Decoupling the @Asynchronous annotation from the EJB component model
* Decoupling the @Lock/@AccessTimeout annotations from the EJB
component model (EJB_SPEC-4)
* Decoupling the @Startup/@DependsOn annotations from the EJB
component model (EJB_SPEC-19)
* Standardize Pooling and Decouple from EJB Component Model (EJB_SPEC-113)
* Redefine Message Driven Beans as Managed Beans (EJB_SPEC-18)
* Standardize Abstractions for Common Message Processing Patterns (JMS_SPEC-154)
* Allow Java EE components other than MDBs to consume messages
* Bind JMS to CDI events and/or business interfaces (JMS_SPEC-88)
* Support for "self" injection (CDI-414)
* Allow access-control related JSR-250 security annotations on managed
* Support @RolesAllowed on a Servlet (SERVLET_SPEC-29)
There are some additional features that may not yet have been covered
(but maybe I missed them), such as:
* Control over passivation
* Support for the extended persistence context
* Destroying a bean whenever an exception occurs (I was just working
on this the other week)
* Logging the exception thrown by a bean (yes, trivial, but part of EJB)
* The concept where every method call on a proxy is routed to another
bean instance, which is then automatically unavailable for other calls
as long as it doesn't return (related to the "Standardize Pooling"
* Binary remoting without all the explicit mapping that's needed for
say JAX-RS (yes, thorny issue which we may not wish to support
* General support for @RolesAllowed/@RunAs etc (often mentioned, and
two issues for JSF managed beans resp Servlets were created, but no
The question is perhaps where all this functionality should live.
TimerService and @Asynchronous in the concurrency spec?
All JMS/messaging listener stuff (aka MDB replacements) in the JMS spec?
@RolesAllowed etc in the security spec (if that spec will actually happen)
@Startup in the CDI spec itself?
Destroying bean on exception in CDI spec?
But where should e.g. pooling belong?
More information about the cdi-dev