<div dir="ltr">It won&#39;t be called &quot;MDBs&quot;, just &quot;Managed Listeners&quot;. The JMS spec will still have listeners and now it will get managed listeners.<div><br></div><div>Antonio</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Nov 17, 2014 at 4:55 PM, Romain Manni-Bucau <span dir="ltr">&lt;<a href="mailto:rmannibucau@gmail.com" target="_blank">rmannibucau@gmail.com</a>&gt;</span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">2014-11-17 16:53 GMT+01:00 Antonio Goncalves &lt;<a href="mailto:antonio.goncalves@gmail.com">antonio.goncalves@gmail.com</a>&gt;:<br>
&gt; @Startup could also make sense in Concurrency in Java EE, like @Pooling<br>
&gt; (there&#39;s thread pools behind).  BTW I was talking to the Oracle guys and it<br>
&gt; looks like the Concurrency spec will be updated in EE 8... I don&#39;t know how<br>
&gt; far the update will go.<br>
&gt;<br>
&gt; As for the JMS stuff, we talked with Nigel and he likes the idea of MDB<br>
&gt; replacement going to where it belongs : the JMS spec<br>
&gt;<br>
<br>
</span>MDBs are not all JMS so IMO MDBs don&#39;t belong to JMS at all. Would be<br>
a big regression to do it. In particular when EE 8/9 will bring nicer<br>
connectors<br>
<div class="HOEnZb"><div class="h5"><br>
&gt; Antonio<br>
&gt;<br>
&gt; On Mon, Nov 17, 2014 at 4:28 PM, arjan tijms &lt;<a href="mailto:arjan.tijms@gmail.com">arjan.tijms@gmail.com</a>&gt; wrote:<br>
&gt;&gt;<br>
&gt;&gt; Hi,<br>
&gt;&gt;<br>
&gt;&gt; On Mon, Nov 17, 2014 at 2:57 PM, Antoine Sabot-Durand<br>
&gt;&gt; &lt;<a href="mailto:antoine@sabot-durand.net">antoine@sabot-durand.net</a>&gt; wrote:<br>
&gt;&gt; &gt; Just to give you a small feedback of my Devoxx week regarding CDI and<br>
&gt;&gt; &gt; CDI 2.0 (for the rest, what happens in Devoxx stays in Devoxx ;) )<br>
&gt;&gt; &gt;<br>
&gt;&gt; &gt; 1) Great expectations:<br>
&gt;&gt; &gt; [...] (the question of total EJB replacement came more than once)<br>
&gt;&gt;<br>
&gt;&gt; I heard this a number of times as well, both before and during Devoxx.<br>
&gt;&gt;<br>
&gt;&gt; A great number of issues for decoupling EJB features (meaning,<br>
&gt;&gt; providing CDI based replacements) have already been created as spec<br>
&gt;&gt; issues:<br>
&gt;&gt;<br>
&gt;&gt; * Decoupling the @Schedule annotation from the EJB component model<br>
&gt;&gt; (EJB_SPEC-1)<br>
&gt;&gt; * Decoupling the TimerService API from the EJB component model<br>
&gt;&gt; (EJB_SPEC-2)<br>
&gt;&gt; * Decoupling the @Asynchronous annotation from the EJB component model<br>
&gt;&gt; (EJB_SPEC-3)<br>
&gt;&gt; * Decoupling the @Lock/@AccessTimeout annotations from the EJB<br>
&gt;&gt; component model (EJB_SPEC-4)<br>
&gt;&gt; * Decoupling the @Startup/@DependsOn annotations from the EJB<br>
&gt;&gt; component model (EJB_SPEC-19)<br>
&gt;&gt; * Standardize Pooling and Decouple from EJB Component Model (EJB_SPEC-113)<br>
&gt;&gt; * Redefine Message Driven Beans as Managed Beans (EJB_SPEC-18)<br>
&gt;&gt; * Standardize Abstractions for Common Message Processing Patterns<br>
&gt;&gt; (JMS_SPEC-154)<br>
&gt;&gt; * Allow Java EE components other than MDBs to consume messages<br>
&gt;&gt; asynchronously (JMS_SPEC-100)<br>
&gt;&gt; * Bind JMS to CDI events and/or business interfaces (JMS_SPEC-88)<br>
&gt;&gt; * Support for &quot;self&quot; injection (CDI-414)<br>
&gt;&gt; * Allow access-control related JSR-250 security annotations on managed<br>
&gt;&gt; beans (JAVASERVERFACES_SPEC_PUBLIC-495)<br>
&gt;&gt; * Support @RolesAllowed on a Servlet (SERVLET_SPEC-29)<br>
&gt;&gt;<br>
&gt;&gt;<br>
&gt;&gt; There are some additional features that may not yet have been covered<br>
&gt;&gt; (but maybe I missed them), such as:<br>
&gt;&gt;<br>
&gt;&gt; * Control over passivation<br>
&gt;&gt; * Support for the extended persistence context<br>
&gt;&gt; * Destroying a bean whenever an exception occurs (I was just working<br>
&gt;&gt; on this the other week)<br>
&gt;&gt; * Logging the exception thrown by a bean (yes, trivial, but part of EJB)<br>
&gt;&gt; * The concept where every method call on a proxy is routed to another<br>
&gt;&gt; bean instance, which is then automatically unavailable for other calls<br>
&gt;&gt; as long as it doesn&#39;t return (related to the &quot;Standardize Pooling&quot;<br>
&gt;&gt; issue)<br>
&gt;&gt; * Binary remoting without all the explicit mapping that&#39;s needed for<br>
&gt;&gt; say JAX-RS  (yes, thorny issue which we may not wish to support<br>
&gt;&gt; anymore?)<br>
&gt;&gt; * General support for @RolesAllowed/@RunAs etc (often mentioned, and<br>
&gt;&gt; two issues for JSF managed beans resp Servlets were created, but no<br>
&gt;&gt; general issue)<br>
&gt;&gt;<br>
&gt;&gt; The question is perhaps where all this functionality should live.<br>
&gt;&gt;<br>
&gt;&gt; TimerService and @Asynchronous in the concurrency spec?<br>
&gt;&gt; All JMS/messaging listener stuff (aka MDB replacements) in the JMS spec?<br>
&gt;&gt; @RolesAllowed etc in the security spec (if that spec will actually happen)<br>
&gt;&gt; @Startup in the CDI spec itself?<br>
&gt;&gt; Destroying bean on exception in CDI spec?<br>
&gt;&gt;<br>
&gt;&gt; But where should e.g. pooling belong?<br>
&gt;&gt;<br>
&gt;&gt; Kind regards,<br>
&gt;&gt; Arjan Tijms<br>
&gt;&gt; _______________________________________________<br>
&gt;&gt; cdi-dev mailing list<br>
&gt;&gt; <a href="mailto:cdi-dev@lists.jboss.org">cdi-dev@lists.jboss.org</a><br>
&gt;&gt; <a href="https://lists.jboss.org/mailman/listinfo/cdi-dev" target="_blank">https://lists.jboss.org/mailman/listinfo/cdi-dev</a><br>
&gt;&gt;<br>
&gt;&gt; Note that for all code provided on this list, the provider licenses the<br>
&gt;&gt; code under the Apache License, Version 2<br>
&gt;&gt; (<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>
&gt;&gt; provided on this list, the provider waives all patent and other intellectual<br>
&gt;&gt; property rights inherent in such information.<br>
&gt;<br>
&gt;<br>
&gt;<br>
&gt;<br>
&gt; --<br>
&gt; Antonio Goncalves<br>
&gt; Software architect, Java Champion and Pluralsight author<br>
&gt;<br>
&gt; Web site | Twitter | LinkedIn | Pluralsight | Paris JUG | Devoxx France<br>
&gt;<br>
&gt; _______________________________________________<br>
&gt; cdi-dev mailing list<br>
&gt; <a href="mailto:cdi-dev@lists.jboss.org">cdi-dev@lists.jboss.org</a><br>
&gt; <a href="https://lists.jboss.org/mailman/listinfo/cdi-dev" target="_blank">https://lists.jboss.org/mailman/listinfo/cdi-dev</a><br>
&gt;<br>
&gt; Note that for all code provided on this list, the provider licenses the code<br>
&gt; under the Apache License, Version 2<br>
&gt; (<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>
&gt; provided on this list, the provider waives all patent and other intellectual<br>
&gt; property rights inherent in such information.<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>