Re: [cdi-dev] Feedback from Devoxx

2014-11-17 21:53 GMT+01:00 Antonio Goncalves <antonio.goncalves(a)gmail.com&gt;: > 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(a)sabot-durand.net&gt; 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(a)gmail.com&gt; 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(a)gmail.com&gt; >> wrote: >>> >>> Hi, >>> >>> On Mon, Nov 17, 2014 at 2:57 PM, Antoine Sabot-Durand >>> <antoine(a)sabot-durand.net&gt; 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(a)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(a)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. _______________________________________________ cdi-dev mailing list cdi-dev(a)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.