[cdi-dev] Feedback from Devoxx

Mon Nov 17 16:10:27 EST 2014

Actually it makes sense, we already have @Transactional so only
security part is really missing from EJB spec - sorry for the noise.

Is there a place with all asked features (JavaSE, @Pooling, easier
SPI, config, ...)? then people could maybe vote?

Romain Manni-Bucau
@rmannibucau
http://www.tomitribe.com
http://rmannibucau.wordpress.com
https://github.com/rmannibucau

2014-11-17 22:04 GMT+01:00 Antonio Goncalves <antonio.goncalves at gmail.com>:
> Like @dblevins once said "EJB was a super hype spec with all the cool
> features... and became blotted throughout the years". If we are not careful,
> CDI (the super hype spec at the moment) will become blotted too.
>
> Context and Dependency Injection should not deal with pooling, scheduling,
> security.... but yes, allow the other specs to implement such concerns. I
> can easily see most of these concerns implemented with interceptor bindings
> or extensions.
>
> When we talked to Nigel (JMS spec lead) he was really enthousiast to learn
> more about CDI and use it to help develop JMS internals. Manfred (JSF / MVC)
> who has already implemented most of the JSF stuff with CDI (@ViewScoped and
> so on) was really encouraging.
>
> I think that part of the job this CDI 2.0 expert group has is to evangelize
> current specs leads to use CDI in their internals.
>
> Antonio
>
> On Mon, Nov 17, 2014 at 9:55 PM, Romain Manni-Bucau <rmannibucau at gmail.com>
> wrote:
>>
>> 2014-11-17 21:53 GMT+01:00 Antonio Goncalves
>> <antonio.goncalves at gmail.com>:
>> > Would you like to see @Inject in JSR 250 ? I don't think it's a good
>> > idea to
>> > put everything in Commons Annotations. It makes sense to have @Startup,
>> > @Pooling, @Scedule, @Asynchronous where it fits better.
>> >
>>
>> Why not keeping in EJBs (even if it needs to be renamed for historical
>> reasons)? ie a spec on top of CDI, not <= CDI.
>>
>> > Antonio
>> >
>> > On Mon, Nov 17, 2014 at 5:30 PM, Antoine Sabot-Durand
>> > <antoine at sabot-durand.net> wrote:
>> >>
>> >> Guys, don’t forget the commons annotation specification since we’re
>> >> going
>> >> to ask for a MR for it. It could be a convenient solution to share
>> >> annotation without having a huge dependency to have it (think of SE).
>> >>
>> >> Antoine
>> >>
>> >>
>> >> Le 17 nov. 2014 à 16:53, Antonio Goncalves
>> >> <antonio.goncalves at gmail.com> a
>> >> écrit :
>> >>
>> >> @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
>> >>
>> >> 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
>> >>
>> >>
>> >
>> >
>> >
>> > --
>> > 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