<div dir="ltr">That's something that has to be discussed in the EE expert group (@arjan pointed at the JIRAs) because, let's face it, nobody really wants to open up the EJB spec (let's leave it quiet, so let's not bring this to the former EJB expert group... which I'm part of ;o)<div><br></div><div>Antonio</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Nov 17, 2014 at 10:10 PM, Romain Manni-Bucau <span dir="ltr"><<a href="mailto:rmannibucau@gmail.com" target="_blank">rmannibucau@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Actually it makes sense, we already have @Transactional so only<br>
security part is really missing from EJB spec - sorry for the noise.<br>
<br>
Is there a place with all asked features (JavaSE, @Pooling, easier<br>
SPI, config, ...)? then people could maybe vote?<br>
<span class="HOEnZb"><font color="#888888"><br>
<br>
Romain Manni-Bucau<br>
@rmannibucau<br>
<a href="http://www.tomitribe.com" target="_blank">http://www.tomitribe.com</a><br>
<a href="http://rmannibucau.wordpress.com" target="_blank">http://rmannibucau.wordpress.com</a><br>
<a href="https://github.com/rmannibucau" target="_blank">https://github.com/rmannibucau</a><br>
</font></span><div class="HOEnZb"><div class="h5"><br>
<br>
2014-11-17 22:04 GMT+01:00 Antonio Goncalves <<a href="mailto:antonio.goncalves@gmail.com">antonio.goncalves@gmail.com</a>>:<br>
> Like @dblevins once said "EJB was a super hype spec with all the cool<br>
> features... and became blotted throughout the years". If we are not careful,<br>
> CDI (the super hype spec at the moment) will become blotted too.<br>
><br>
> Context and Dependency Injection should not deal with pooling, scheduling,<br>
> security.... but yes, allow the other specs to implement such concerns. I<br>
> can easily see most of these concerns implemented with interceptor bindings<br>
> or extensions.<br>
><br>
> When we talked to Nigel (JMS spec lead) he was really enthousiast to learn<br>
> more about CDI and use it to help develop JMS internals. Manfred (JSF / MVC)<br>
> who has already implemented most of the JSF stuff with CDI (@ViewScoped and<br>
> so on) was really encouraging.<br>
><br>
> I think that part of the job this CDI 2.0 expert group has is to evangelize<br>
> current specs leads to use CDI in their internals.<br>
><br>
> Antonio<br>
><br>
> On Mon, Nov 17, 2014 at 9:55 PM, Romain Manni-Bucau <<a href="mailto:rmannibucau@gmail.com">rmannibucau@gmail.com</a>><br>
> wrote:<br>
>><br>
>> 2014-11-17 21:53 GMT+01:00 Antonio Goncalves<br>
>> <<a href="mailto:antonio.goncalves@gmail.com">antonio.goncalves@gmail.com</a>>:<br>
>> > Would you like to see @Inject in JSR 250 ? I don't think it's a good<br>
>> > idea to<br>
>> > put everything in Commons Annotations. It makes sense to have @Startup,<br>
>> > @Pooling, @Scedule, @Asynchronous where it fits better.<br>
>> ><br>
>><br>
>> Why not keeping in EJBs (even if it needs to be renamed for historical<br>
>> reasons)? ie a spec on top of CDI, not <= CDI.<br>
>><br>
>> > Antonio<br>
>> ><br>
>> > On Mon, Nov 17, 2014 at 5:30 PM, Antoine Sabot-Durand<br>
>> > <<a href="mailto:antoine@sabot-durand.net">antoine@sabot-durand.net</a>> wrote:<br>
>> >><br>
>> >> Guys, don’t forget the commons annotation specification since we’re<br>
>> >> going<br>
>> >> to ask for a MR for it. It could be a convenient solution to share<br>
>> >> annotation without having a huge dependency to have it (think of SE).<br>
>> >><br>
>> >> Antoine<br>
>> >><br>
>> >><br>
>> >> Le 17 nov. 2014 à 16:53, Antonio Goncalves<br>
>> >> <<a href="mailto:antonio.goncalves@gmail.com">antonio.goncalves@gmail.com</a>> a<br>
>> >> écrit :<br>
>> >><br>
>> >> @Startup could also make sense in Concurrency in Java EE, like @Pooling<br>
>> >> (there's thread pools behind). BTW I was talking to the Oracle guys<br>
>> >> and it<br>
>> >> looks like the Concurrency spec will be updated in EE 8... I don't know<br>
>> >> how<br>
>> >> far the update will go.<br>
>> >><br>
>> >> As for the JMS stuff, we talked with Nigel and he likes the idea of MDB<br>
>> >> replacement going to where it belongs : the JMS spec<br>
>> >><br>
>> >> Antonio<br>
>> >><br>
>> >> On Mon, Nov 17, 2014 at 4:28 PM, arjan tijms <<a href="mailto:arjan.tijms@gmail.com">arjan.tijms@gmail.com</a>><br>
>> >> wrote:<br>
>> >>><br>
>> >>> Hi,<br>
>> >>><br>
>> >>> On Mon, Nov 17, 2014 at 2:57 PM, Antoine Sabot-Durand<br>
>> >>> <<a href="mailto:antoine@sabot-durand.net">antoine@sabot-durand.net</a>> wrote:<br>
>> >>> > Just to give you a small feedback of my Devoxx week regarding CDI<br>
>> >>> > and<br>
>> >>> > CDI 2.0 (for the rest, what happens in Devoxx stays in Devoxx ;) )<br>
>> >>> ><br>
>> >>> > 1) Great expectations:<br>
>> >>> > [...] (the question of total EJB replacement came more than once)<br>
>> >>><br>
>> >>> I heard this a number of times as well, both before and during Devoxx.<br>
>> >>><br>
>> >>> A great number of issues for decoupling EJB features (meaning,<br>
>> >>> providing CDI based replacements) have already been created as spec<br>
>> >>> issues:<br>
>> >>><br>
>> >>> * Decoupling the @Schedule annotation from the EJB component model<br>
>> >>> (EJB_SPEC-1)<br>
>> >>> * Decoupling the TimerService API from the EJB component model<br>
>> >>> (EJB_SPEC-2)<br>
>> >>> * Decoupling the @Asynchronous annotation from the EJB component model<br>
>> >>> (EJB_SPEC-3)<br>
>> >>> * Decoupling the @Lock/@AccessTimeout annotations from the EJB<br>
>> >>> component model (EJB_SPEC-4)<br>
>> >>> * Decoupling the @Startup/@DependsOn annotations from the EJB<br>
>> >>> component model (EJB_SPEC-19)<br>
>> >>> * Standardize Pooling and Decouple from EJB Component Model<br>
>> >>> (EJB_SPEC-113)<br>
>> >>> * Redefine Message Driven Beans as Managed Beans (EJB_SPEC-18)<br>
>> >>> * Standardize Abstractions for Common Message Processing Patterns<br>
>> >>> (JMS_SPEC-154)<br>
>> >>> * Allow Java EE components other than MDBs to consume messages<br>
>> >>> asynchronously (JMS_SPEC-100)<br>
>> >>> * Bind JMS to CDI events and/or business interfaces (JMS_SPEC-88)<br>
>> >>> * Support for "self" injection (CDI-414)<br>
>> >>> * Allow access-control related JSR-250 security annotations on managed<br>
>> >>> beans (JAVASERVERFACES_SPEC_PUBLIC-495)<br>
>> >>> * Support @RolesAllowed on a Servlet (SERVLET_SPEC-29)<br>
>> >>><br>
>> >>><br>
>> >>> There are some additional features that may not yet have been covered<br>
>> >>> (but maybe I missed them), such as:<br>
>> >>><br>
>> >>> * Control over passivation<br>
>> >>> * Support for the extended persistence context<br>
>> >>> * Destroying a bean whenever an exception occurs (I was just working<br>
>> >>> on this the other week)<br>
>> >>> * Logging the exception thrown by a bean (yes, trivial, but part of<br>
>> >>> EJB)<br>
>> >>> * The concept where every method call on a proxy is routed to another<br>
>> >>> bean instance, which is then automatically unavailable for other calls<br>
>> >>> as long as it doesn't return (related to the "Standardize Pooling"<br>
>> >>> issue)<br>
>> >>> * Binary remoting without all the explicit mapping that's needed for<br>
>> >>> say JAX-RS (yes, thorny issue which we may not wish to support<br>
>> >>> anymore?)<br>
>> >>> * General support for @RolesAllowed/@RunAs etc (often mentioned, and<br>
>> >>> two issues for JSF managed beans resp Servlets were created, but no<br>
>> >>> general issue)<br>
>> >>><br>
>> >>> The question is perhaps where all this functionality should live.<br>
>> >>><br>
>> >>> TimerService and @Asynchronous in the concurrency spec?<br>
>> >>> All JMS/messaging listener stuff (aka MDB replacements) in the JMS<br>
>> >>> spec?<br>
>> >>> @RolesAllowed etc in the security spec (if that spec will actually<br>
>> >>> happen)<br>
>> >>> @Startup in the CDI spec itself?<br>
>> >>> Destroying bean on exception in CDI spec?<br>
>> >>><br>
>> >>> But where should e.g. pooling belong?<br>
>> >>><br>
>> >>> Kind regards,<br>
>> >>> Arjan Tijms<br>
>> >>> _______________________________________________<br>
>> >>> cdi-dev mailing list<br>
>> >>> <a href="mailto:cdi-dev@lists.jboss.org">cdi-dev@lists.jboss.org</a><br>
>> >>> <a href="https://lists.jboss.org/mailman/listinfo/cdi-dev" target="_blank">https://lists.jboss.org/mailman/listinfo/cdi-dev</a><br>
>> >>><br>
>> >>> Note that for all code provided on this list, the provider licenses<br>
>> >>> the<br>
>> >>> code under the Apache License, Version 2<br>
>> >>> (<a href="http://www.apache.org/licenses/LICENSE-2.0.html" target="_blank">http://www.apache.org/licenses/LICENSE-2.0.html</a>). For all other ideas<br>
>> >>> provided on this list, the provider waives all patent and other<br>
>> >>> intellectual<br>
>> >>> property rights inherent in such information.<br>
>> >><br>
>> >><br>
>> >><br>
>> >><br>
>> >> --<br>
>> >> Antonio Goncalves<br>
>> >> Software architect, Java Champion and Pluralsight author<br>
>> >><br>
>> >> Web site | Twitter | LinkedIn | Pluralsight | Paris JUG | Devoxx France<br>
>> >><br>
>> >><br>
>> ><br>
>> ><br>
>> ><br>
>> > --<br>
>> > Antonio Goncalves<br>
>> > Software architect, Java Champion and Pluralsight author<br>
>> ><br>
>> > Web site | Twitter | LinkedIn | Pluralsight | Paris JUG | Devoxx France<br>
>> ><br>
>> > _______________________________________________<br>
>> > cdi-dev mailing list<br>
>> > <a href="mailto:cdi-dev@lists.jboss.org">cdi-dev@lists.jboss.org</a><br>
>> > <a href="https://lists.jboss.org/mailman/listinfo/cdi-dev" target="_blank">https://lists.jboss.org/mailman/listinfo/cdi-dev</a><br>
>> ><br>
>> > Note that for all code provided on this list, the provider licenses the<br>
>> > code<br>
>> > under the Apache License, Version 2<br>
>> > (<a href="http://www.apache.org/licenses/LICENSE-2.0.html" target="_blank">http://www.apache.org/licenses/LICENSE-2.0.html</a>). For all other ideas<br>
>> > provided on this list, the provider waives all patent and other<br>
>> > intellectual<br>
>> > property rights inherent in such information.<br>
><br>
><br>
><br>
><br>
> --<br>
> Antonio Goncalves<br>
> Software architect, Java Champion and Pluralsight author<br>
><br>
> Web site | Twitter | LinkedIn | Pluralsight | Paris JUG | Devoxx France<br>
</div></div></blockquote></div><br><br clear="all"><div><br></div>-- <br><div class="gmail_signature"><div dir="ltr">Antonio Goncalves <br>Software architect, Java Champion and Pluralsight author<br><br><a href="http://www.antoniogoncalves.org" target="_blank">Web site</a> | <a href="http://twitter.com/agoncal" target="_blank">Twitter</a> | <a href="http://www.linkedin.com/in/agoncal" target="_blank">LinkedIn</a> | <a href="http://pluralsight.com/training/Authors/Details/antonio-goncalves" target="_blank">Pluralsight</a> | <a href="http://www.parisjug.org" target="_blank">Paris JUG</a> | <a href="http://www.devoxx.fr" target="_blank">Devoxx France</a></div></div>
</div>