<div dir="ltr">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. <div><br></div><div>Antonio</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Nov 17, 2014 at 5:30 PM, Antoine Sabot-Durand <span dir="ltr"><<a href="mailto:antoine@sabot-durand.net" target="_blank">antoine@sabot-durand.net</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word"><div>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).</div><div><br></div><div>Antoine</div><div><br></div><br><div><blockquote type="cite"><div>Le 17 nov. 2014 à 16:53, Antonio Goncalves <<a href="mailto:antonio.goncalves@gmail.com" target="_blank">antonio.goncalves@gmail.com</a>> a écrit :</div><div><div class="h5"><br><div><div dir="ltr"><span style="font-family:arial,sans-serif;font-size:12.7272720336914px">@Startup could also make sense in Concurrency in Java EE, like @Pooling (there's thread pools behind). </span><span style="font-family:arial,sans-serif;font-size:12.7272720336914px">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.</span><div><div><span style="font-family:arial,sans-serif;font-size:12.7272720336914px"><br></span></div><div><span style="font-family:arial,sans-serif;font-size:12.7272720336914px">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</span><span style="font-family:arial,sans-serif;font-size:12.7272720336914px"><br></span></div><div><span style="font-family:arial,sans-serif;font-size:12.7272720336914px"><br></span></div><div><span style="font-family:arial,sans-serif;font-size:12.7272720336914px">Antonio</span></div></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Nov 17, 2014 at 4:28 PM, arjan tijms <span dir="ltr"><<a href="mailto:arjan.tijms@gmail.com" target="_blank">arjan.tijms@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi,<br>
<span><br>
On Mon, Nov 17, 2014 at 2:57 PM, Antoine Sabot-Durand<br>
<<a href="mailto:antoine@sabot-durand.net" target="_blank">antoine@sabot-durand.net</a>> wrote:<br>
> 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 ;) )<br>
><br>
> 1) Great expectations:<br>
</span>> [...] (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 (EJB_SPEC-1)<br>
* Decoupling the TimerService API from the EJB component model (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 (EJB_SPEC-113)<br>
* Redefine Message Driven Beans as Managed Beans (EJB_SPEC-18)<br>
* Standardize Abstractions for Common Message Processing Patterns (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 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 spec?<br>
@RolesAllowed etc in the security spec (if that spec will actually 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>
<div><div>_______________________________________________<br>
cdi-dev mailing list<br>
<a href="mailto:cdi-dev@lists.jboss.org" target="_blank">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 code under the Apache License, Version 2 (<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 provided on this list, the provider waives all patent and other intellectual property rights inherent in such information.<br>
</div></div></blockquote></div><br><br clear="all"><div><br></div>-- <br><div><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>
</div></div></div></blockquote></div><br></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>