<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><br class=""><div><blockquote type="cite" class=""><div class="">Le 17 nov. 2014 à 21:53, Antonio Goncalves <<a href="mailto:antonio.goncalves@gmail.com" class="">antonio.goncalves@gmail.com</a>> a écrit :</div><br class="Apple-interchange-newline"><div class=""><div dir="ltr" class="">Would you like to see @Inject in JSR 250 ?</div></div></blockquote><div><br class=""></div><div>No, but in the end it’s a good thing that it is not in CDI (in a far lighter spec), so it can be used by other DI solution for the sake of end users.</div><br class=""><blockquote type="cite" class=""><div class=""><div dir="ltr" class="">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></div></blockquote><div><br class=""></div><div>Again, it’s a only Java EE pov, having such dependencies in Java SE can be a real handicap. Take @Startup for instance. Its purpose is to make sure that a bean is instantiated at startup. Why in the hell would I want to drag all the concurrency spec to only have this annotation ?</div><div>I don’t say that it’s the case for all annotations, but we should really consider having this multiple purpose annotation in light spec. For instance I’m not against having our @Produces moved to AtInject (and perhaps renamed to @Provides to end the mix with JAX-RX Produces) to share this concept with all other implementations.</div><br class=""><blockquote type="cite" class=""><div class=""><div dir="ltr" class=""><div class=""><br class=""></div><div class="">Antonio</div></div><div class="gmail_extra"><br class=""><div class="gmail_quote">On Mon, Nov 17, 2014 at 5:30 PM, Antoine Sabot-Durand <span dir="ltr" class=""><<a href="mailto:antoine@sabot-durand.net" target="_blank" class="">antoine@sabot-durand.net</a>></span> wrote:<br class=""><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word" class=""><div class="">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 class=""><br class=""></div><div class="">Antoine</div><div class=""><br class=""></div><br class=""><div class=""><blockquote type="cite" class=""><div class="">Le 17 nov. 2014 à 16:53, Antonio Goncalves <<a href="mailto:antonio.goncalves@gmail.com" target="_blank" class="">antonio.goncalves@gmail.com</a>> a écrit :</div><div class=""><div class="h5"><br class=""><div class=""><div dir="ltr" class=""><span style="font-family:arial,sans-serif;font-size:12.7272720336914px" class="">@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" class="">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 class=""><div class=""><span style="font-family:arial,sans-serif;font-size:12.7272720336914px" class=""><br class=""></span></div><div class=""><span style="font-family:arial,sans-serif;font-size:12.7272720336914px" class="">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" class=""><br class=""></span></div><div class=""><span style="font-family:arial,sans-serif;font-size:12.7272720336914px" class=""><br class=""></span></div><div class=""><span style="font-family:arial,sans-serif;font-size:12.7272720336914px" class="">Antonio</span></div></div></div><div class="gmail_extra"><br class=""><div class="gmail_quote">On Mon, Nov 17, 2014 at 4:28 PM, arjan tijms <span dir="ltr" class=""><<a href="mailto:arjan.tijms@gmail.com" target="_blank" class="">arjan.tijms@gmail.com</a>></span> wrote:<br class=""><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi,<br class="">
<span class=""><br class="">
On Mon, Nov 17, 2014 at 2:57 PM, Antoine Sabot-Durand<br class="">
<<a href="mailto:antoine@sabot-durand.net" target="_blank" class="">antoine@sabot-durand.net</a>> wrote:<br class="">
> 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 class="">
><br class="">
> 1) Great expectations:<br class="">
</span>> [...] (the question of total EJB replacement came more than once)<br class="">
<br class="">
I heard this a number of times as well, both before and during Devoxx.<br class="">
<br class="">
A great number of issues for decoupling EJB features (meaning,<br class="">
providing CDI based replacements) have already been created as spec<br class="">
issues:<br class="">
<br class="">
* Decoupling the @Schedule annotation from the EJB component model (EJB_SPEC-1)<br class="">
* Decoupling the TimerService API from the EJB component model (EJB_SPEC-2)<br class="">
* Decoupling the @Asynchronous annotation from the EJB component model<br class="">
(EJB_SPEC-3)<br class="">
* Decoupling the @Lock/@AccessTimeout annotations from the EJB<br class="">
component model (EJB_SPEC-4)<br class="">
* Decoupling the @Startup/@DependsOn annotations from the EJB<br class="">
component model (EJB_SPEC-19)<br class="">
* Standardize Pooling and Decouple from EJB Component Model (EJB_SPEC-113)<br class="">
* Redefine Message Driven Beans as Managed Beans (EJB_SPEC-18)<br class="">
* Standardize Abstractions for Common Message Processing Patterns (JMS_SPEC-154)<br class="">
* Allow Java EE components other than MDBs to consume messages<br class="">
asynchronously (JMS_SPEC-100)<br class="">
* Bind JMS to CDI events and/or business interfaces (JMS_SPEC-88)<br class="">
* Support for "self" injection (CDI-414)<br class="">
* Allow access-control related JSR-250 security annotations on managed<br class="">
beans (JAVASERVERFACES_SPEC_PUBLIC-495)<br class="">
* Support @RolesAllowed on a Servlet (SERVLET_SPEC-29)<br class="">
<br class="">
<br class="">
There are some additional features that may not yet have been covered<br class="">
(but maybe I missed them), such as:<br class="">
<br class="">
* Control over passivation<br class="">
* Support for the extended persistence context<br class="">
* Destroying a bean whenever an exception occurs (I was just working<br class="">
on this the other week)<br class="">
* Logging the exception thrown by a bean (yes, trivial, but part of EJB)<br class="">
* The concept where every method call on a proxy is routed to another<br class="">
bean instance, which is then automatically unavailable for other calls<br class="">
as long as it doesn't return (related to the "Standardize Pooling"<br class="">
issue)<br class="">
* Binary remoting without all the explicit mapping that's needed for<br class="">
say JAX-RS (yes, thorny issue which we may not wish to support<br class="">
anymore?)<br class="">
* General support for @RolesAllowed/@RunAs etc (often mentioned, and<br class="">
two issues for JSF managed beans resp Servlets were created, but no<br class="">
general issue)<br class="">
<br class="">
The question is perhaps where all this functionality should live.<br class="">
<br class="">
TimerService and @Asynchronous in the concurrency spec?<br class="">
All JMS/messaging listener stuff (aka MDB replacements) in the JMS spec?<br class="">
@RolesAllowed etc in the security spec (if that spec will actually happen)<br class="">
@Startup in the CDI spec itself?<br class="">
Destroying bean on exception in CDI spec?<br class="">
<br class="">
But where should e.g. pooling belong?<br class="">
<br class="">
Kind regards,<br class="">
Arjan Tijms<br class="">
<div class=""><div class="">_______________________________________________<br class="">
cdi-dev mailing list<br class="">
<a href="mailto:cdi-dev@lists.jboss.org" target="_blank" class="">cdi-dev@lists.jboss.org</a><br class="">
<a href="https://lists.jboss.org/mailman/listinfo/cdi-dev" target="_blank" class="">https://lists.jboss.org/mailman/listinfo/cdi-dev</a><br class="">
<br class="">
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" class="">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 class="">
</div></div></blockquote></div><br class=""><br clear="all" class=""><div class=""><br class=""></div>-- <br class=""><div class=""><div dir="ltr" class="">Antonio Goncalves <br class="">Software architect, Java Champion and Pluralsight author<br class=""><br class=""><a href="http://www.antoniogoncalves.org/" target="_blank" class="">Web site</a> | <a href="http://twitter.com/agoncal" target="_blank" class="">Twitter</a> | <a href="http://www.linkedin.com/in/agoncal" target="_blank" class="">LinkedIn</a> | <a href="http://pluralsight.com/training/Authors/Details/antonio-goncalves" target="_blank" class="">Pluralsight</a> | <a href="http://www.parisjug.org/" target="_blank" class="">Paris JUG</a> | <a href="http://www.devoxx.fr/" target="_blank" class="">Devoxx France</a></div></div>
</div>
</div></div></div></blockquote></div><br class=""></div></blockquote></div><br class=""><br clear="all" class=""><div class=""><br class=""></div>-- <br class=""><div class="gmail_signature"><div dir="ltr" class="">Antonio Goncalves <br class="">Software architect, Java Champion and Pluralsight author<br class=""><br class=""><a href="http://www.antoniogoncalves.org/" target="_blank" class="">Web site</a> | <a href="http://twitter.com/agoncal" target="_blank" class="">Twitter</a> | <a href="http://www.linkedin.com/in/agoncal" target="_blank" class="">LinkedIn</a> | <a href="http://pluralsight.com/training/Authors/Details/antonio-goncalves" target="_blank" class="">Pluralsight</a> | <a href="http://www.parisjug.org/" target="_blank" class="">Paris JUG</a> | <a href="http://www.devoxx.fr/" target="_blank" class="">Devoxx France</a></div></div>
</div>
</div></blockquote></div><br class=""></body></html>