[cdi-dev] Feedback from Devoxx

Antonio Goncalves antonio.goncalves at gmail.com
Mon Nov 17 10:58:36 EST 2014


It won't be called "MDBs", just "Managed Listeners". The JMS spec will
still have listeners and now it will get managed listeners.

Antonio

On Mon, Nov 17, 2014 at 4:55 PM, Romain Manni-Bucau <rmannibucau at gmail.com>
wrote:

> 2014-11-17 16:53 GMT+01:00 Antonio Goncalves <antonio.goncalves at gmail.com
> >:
> > @Startup could also make sense in Concurrency in Java EE, like @Pooling
> > (there's thread pools behind).  BTW I was talking to the Oracle guys and
> it
> > looks like the Concurrency spec will be updated in EE 8... I don't know
> how
> > far the update will go.
> >
> > As for the JMS stuff, we talked with Nigel and he likes the idea of MDB
> > replacement going to where it belongs : the JMS spec
> >
>
> MDBs are not all JMS so IMO MDBs don't belong to JMS at all. Would be
> a big regression to do it. In particular when EE 8/9 will bring nicer
> connectors
>
> > Antonio
> >
> > On Mon, Nov 17, 2014 at 4:28 PM, arjan tijms <arjan.tijms at gmail.com>
> wrote:
> >>
> >> Hi,
> >>
> >> 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
> >> 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 at 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.
> >
> >
> >
> >
> > --
> > Antonio Goncalves
> > Software architect, Java Champion and Pluralsight author
> >
> > Web site | Twitter | LinkedIn | Pluralsight | Paris JUG | Devoxx France
> >
> > _______________________________________________
> > cdi-dev mailing list
> > cdi-dev at 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.
>



-- 
Antonio Goncalves
Software architect, Java Champion and Pluralsight author

Web site <http://www.antoniogoncalves.org> | Twitter
<http://twitter.com/agoncal> | LinkedIn <http://www.linkedin.com/in/agoncal> |
Pluralsight
<http://pluralsight.com/training/Authors/Details/antonio-goncalves> | Paris
JUG <http://www.parisjug.org> | Devoxx France <http://www.devoxx.fr>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20141117/79877f1b/attachment.html 


More information about the cdi-dev mailing list