[cdi-dev] Feedback from Devoxx

[Romain Manni-Bucau]

2014-11-17 16:58 GMT+01:00 Antonio Goncalves <antonio.goncalves at gmail.com>:
> It won't be called "MDBs", just "Managed Listeners". The JMS spec will still
> have listeners and now it will get managed listeners.
>

Ok get it, what I meant was mainly that connectors should integrate
with CDI rather than doing anything specific for MDBs, no?

> 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 | Twitter | LinkedIn | Pluralsight | Paris JUG | Devoxx France