Hi,
On Mon, Nov 17, 2014 at 2:57 PM, Antoine Sabot-Durand
<antoine@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
issues:
* 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
(EJB_SPEC-3)
* 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
asynchronously (JMS_SPEC-100)
* 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
beans (JAVASERVERFACES_SPEC_PUBLIC-495)
* 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"
issue)
* Binary remoting without all the explicit mapping that's needed for
say JAX-RS (yes, thorny issue which we may not wish to support
anymore?)
* General support for @RolesAllowed/@RunAs etc (often mentioned, and
two issues for JSF managed beans resp Servlets were created, but no
general issue)
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?
Kind regards,
Arjan Tijms
_______________________________________________
cdi-dev mailing list
cdi-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/cdi-dev
Note that for all code provided on this list, the provider licenses the code under the Apache License, Version 2 (http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas provided on this list, the provider waives all patent and other intellectual property rights inherent in such information.