Le 19 mars 2015 à 15:51, Romain Manni-Bucau <rmannibucau(a)gmail.com&gt; a écrit : sounds like a quick and dirty solution to me. @Async will arrive

- maybe too early today - but adding @ObservesAsync just cause we dont have yet @Async will make this API obselete pretty quickly isn't it (already cause of EJB actually).

Do we really want this feature at this price?

If yes AsyncObserves sounds an acceptable compromise but still will mess up the API IMO.

Romain Manni-Bucau @rmannibucau <https://twitter.com/rmannibucau> | Blog <http://rmannibucau.wordpress.com/> | Github <https://github.com/rmannibucau> | LinkedIn <https://www.linkedin.com/in/rmannibucau> | Tomitriber <http://www.tomitribe.com/> 2015-03-19 15:36 GMT+01:00 Antoine Sabot-Durand <antoine(a)sabot-durand.net <mailto:antoine@sabot-durand.net>>: Hi guys, So it seems impossible to avoid opt-in on the observer side for the sake of awkward compatibility. Adding a member to @Observes could also be a source of issues when old CDI lib will be used with CDI 2.0 runtime. Some of us (including me) don’t want to add an @Async annotation to CDI spec, so perhaps we should add an async alternative to @Observes with an @AsyncObserves or @ObservesAsync ? So it would be public void myObserver(@AsyncObserves payload) {} instead of @Async public void myObserver(@Observes payload) {} Pros : - it’s a cleaner way to manage the opt-in than to put 2 annotations or add a member to an existing one - it could have new members related to async behavior (context propagation, concurrent scenario, etc…) - As it won’t be in legacy code no risk to see old observers called asynchronously Cons : - Still not clear for users when fire() is called to see @AsyncObserves launched synchronously - Yet another annotation added wdyt ? Antoine _______________________________________________ cdi-dev mailing list cdi-dev(a)lists.jboss.org <mailto:cdi-dev@lists.jboss.org> https://lists.jboss.org/mailman/listinfo/cdi-dev <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 <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.

Le 19 mars 2015 à 16:52, José Paumard <jose.paumard(a)gmail.com&gt; a écrit : > So it seems impossible to avoid opt-in on the observer side What is the "killer" argument for that ? José 2015-03-19 16:44 GMT+01:00 Antoine Sabot-Durand <antoine(a)sabot-durand.net <mailto:antoine@sabot-durand.net>>: > Le 19 mars 2015 à 15:51, Romain Manni-Bucau <rmannibucau(a)gmail.com <mailto:rmannibucau@gmail.com>> a écrit : > > sounds like a quick and dirty solution to me. @Async will arrive Yes like in “Async is coming” ;) > - maybe too early today - but adding @ObservesAsync just cause we dont have yet @Async will make this API obselete pretty quickly isn't it (already cause of EJB actually). and if we add an @Async in our spec you think it’s better ? > > Do we really want this feature at this price? #1 requested feature by users. > If yes AsyncObserves sounds an acceptable compromise but still will mess up the API IMO. The question is “Is it more or less messy than @Async @Observes?" I don’t know… It has pros and cons as I listed... > > > Romain Manni-Bucau > @rmannibucau <https://twitter.com/rmannibucau> | Blog <http://rmannibucau.wordpress.com/> | Github <https://github.com/rmannibucau> | LinkedIn <https://www.linkedin.com/in/rmannibucau> | Tomitriber <http://www.tomitribe.com/> > 2015-03-19 15:36 GMT+01:00 Antoine Sabot-Durand <antoine(a)sabot-durand.net <mailto:antoine@sabot-durand.net>>: > Hi guys, > > > So it seems impossible to avoid opt-in on the observer side for the sake of awkward compatibility. > Adding a member to @Observes could also be a source of issues when old CDI lib will be used with CDI 2.0 runtime. Some of us (including me) don’t want to add an @Async annotation to CDI spec, so perhaps we should add an async alternative to @Observes with an @AsyncObserves or @ObservesAsync ? > > So it would be > > public void myObserver(@AsyncObserves payload) {} > > instead of > > @Async > public void myObserver(@Observes payload) {} > > > Pros : > - it’s a cleaner way to manage the opt-in than to put 2 annotations or add a member to an existing one > - it could have new members related to async behavior (context propagation, concurrent scenario, etc…) > - As it won’t be in legacy code no risk to see old observers called asynchronously > > Cons : > - Still not clear for users when fire() is called to see @AsyncObserves launched synchronously > - Yet another annotation added > > wdyt ? > > Antoine > > _______________________________________________ > cdi-dev mailing list > cdi-dev(a)lists.jboss.org <mailto:cdi-dev@lists.jboss.org> > https://lists.jboss.org/mailman/listinfo/cdi-dev <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 <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 <mailto:cdi-dev@lists.jboss.org> https://lists.jboss.org/mailman/listinfo/cdi-dev <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 <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. -- Java le soir <http://blog.paumard.org/> Cours Java en ligne <http://blog.paumard.org/cours-tutoriaux/> Twitter <http://twitter.com/#!/JosePaumard> Paris JUG <http://www.parisjug.org/> Devoxx France <http://www.devoxx.fr/> M : +33 6 76 82 91 47

Am 19.03.2015 um 18:17 schrieb José Paumard <jose.paumard(a)gmail.com&gt;: I see the situation as being : - CDI 1.x : I call event.fireEvent(...), there is an observer that is called. Currently it is called in the same thread. - CDI 2.0 : I call event.fireEvent(...), there is an observer that is called. It will be called in the same thread. So what is the backward compatibility issue here ? From what I understand it just works the same. José 2015-03-19 17:19 GMT+01:00 Antoine Sabot-Durand <antoine(a)sabot-durand.net&gt;: The killer argument is that nobody succeed to provide a way to prevent opt-in and keep backward compaibility. The problem comes from the fact that producer and consumer can be in different jar compiled with different version of CDI and running on CDI 2.0 preventing using opt-out. If you have the solution without opt-in I’m all ears. > Le 19 mars 2015 à 16:52, José Paumard <jose.paumard(a)gmail.com&gt; a écrit : > > > So it seems impossible to avoid opt-in on the observer side > What is the "killer" argument for that ? > > José > > 2015-03-19 16:44 GMT+01:00 Antoine Sabot-Durand <antoine(a)sabot-durand.net&gt;: > >> Le 19 mars 2015 à 15:51, Romain Manni-Bucau <rmannibucau(a)gmail.com&gt; a écrit : >> >> sounds like a quick and dirty solution to me. @Async will arrive > > Yes like in “Async is coming” ;) > >> - maybe too early today - but adding @ObservesAsync just cause we dont have yet @Async will make this API obselete pretty quickly isn't it (already cause of EJB actually). > > and if we add an @Async in our spec you think it’s better ? > >> >> Do we really want this feature at this price? > > #1 requested feature by users. > >> If yes AsyncObserves sounds an acceptable compromise but still will mess up the API IMO. > > The question is “Is it more or less messy than @Async @Observes?" I don’t know… It has pros and cons as I listed... > >> >> >> Romain Manni-Bucau >> @rmannibucau | Blog | Github | LinkedIn | Tomitriber >> >> 2015-03-19 15:36 GMT+01:00 Antoine Sabot-Durand <antoine(a)sabot-durand.net&gt;: >> Hi guys, >> >> >> So it seems impossible to avoid opt-in on the observer side for the sake of awkward compatibility. >> Adding a member to @Observes could also be a source of issues when old CDI lib will be used with CDI 2.0 runtime. Some of us (including me) don’t want to add an @Async annotation to CDI spec, so perhaps we should add an async alternative to @Observes with an @AsyncObserves or @ObservesAsync ? >> >> So it would be >> >> public void myObserver(@AsyncObserves payload) {} >> >> instead of >> >> @Async >> public void myObserver(@Observes payload) {} >> >> >> Pros : >> - it’s a cleaner way to manage the opt-in than to put 2 annotations or add a member to an existing one >> - it could have new members related to async behavior (context propagation, concurrent scenario, etc…) >> - As it won’t be in legacy code no risk to see old observers called asynchronously >> >> Cons : >> - Still not clear for users when fire() is called to see @AsyncObserves launched synchronously >> - Yet another annotation added >> >> wdyt ? >> >> Antoine >> >> _______________________________________________ >> 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. > > > > -- > Java le soir Cours Java en ligne > Twitter Paris JUG Devoxx France > M : +33 6 76 82 91 47 -- Java le soir Cours Java en ligne Twitter Paris JUG Devoxx France M : +33 6 76 82 91 47 _______________________________________________ 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.

Am 19.03.2015 um 21:04 schrieb Jens Schumann <jens.schumann(a)openknowledge.de&gt;: Is this a spec related backward compatibility issue at all? Sounds like a major contract break on application level. Nothing we (CDI) can do here. Jens Am 19/03/15 20:43 schrieb "Mark Struberg" unter <struberg(a)yahoo.de&gt;: > Imagine you write some business code and your Observer needs a > @RequestScoped LoggedInUser. > The event gets fired by some cool library you use. > > Now this cool library updates to CDI-2.0 and uses fireAsync from now on. > But your code still needs the @RequestScoped LoggedInUser on the same > thread -> booooom. > > LieGrue, > strub > >> Am 19.03.2015 um 18:17 schrieb José Paumard <jose.paumard(a)gmail.com&gt;: >> >> I see the situation as being : >> - CDI 1.x : I call event.fireEvent(...), there is an observer that is >> called. Currently it is called in the same thread. >> - CDI 2.0 : I call event.fireEvent(...), there is an observer that is >> called. It will be called in the same thread. >> >> So what is the backward compatibility issue here ? From what I >> understand it just works the same. >> >> José >> >> >> 2015-03-19 17:19 GMT+01:00 Antoine Sabot-Durand >> <antoine(a)sabot-durand.net&gt;: >> The killer argument is that nobody succeed to provide a way to prevent >> opt-in and keep backward compaibility. The problem comes from the fact >> that producer and consumer can be in different jar compiled with >> different version of CDI and running on CDI 2.0 preventing using >> opt-out. >> If you have the solution without opt-in I¹m all ears. >> >> >>> Le 19 mars 2015 à 16:52, José Paumard <jose.paumard(a)gmail.com&gt; a écrit >>> : >>> >>>> So it seems impossible to avoid opt-in on the observer side >>> What is the "killer" argument for that ? >>> >>> José >>> >>> 2015-03-19 16:44 GMT+01:00 Antoine Sabot-Durand >>> <antoine(a)sabot-durand.net&gt;: >>> >>>> Le 19 mars 2015 à 15:51, Romain Manni-Bucau <rmannibucau(a)gmail.com&gt; a >>>> écrit : >>>> >>>> sounds like a quick and dirty solution to me. @Async will arrive >>> >>> Yes like in ³Async is coming² ;) >>> >>>> - maybe too early today - but adding @ObservesAsync just cause we >>>> dont have yet @Async will make this API obselete pretty quickly isn't >>>> it (already cause of EJB actually). >>> >>> and if we add an @Async in our spec you think it¹s better ? >>> >>>> >>>> Do we really want this feature at this price? >>> >>> #1 requested feature by users. >>> >>>> If yes AsyncObserves sounds an acceptable compromise but still will >>>> mess up the API IMO. >>> >>> The question is ³Is it more or less messy than @Async @Observes?" I >>> don¹t knowŠ It has pros and cons as I listed... >>> >>>> >>>> >>>> Romain Manni-Bucau >>>> @rmannibucau | Blog | Github | LinkedIn | Tomitriber >>>> >>>> 2015-03-19 15:36 GMT+01:00 Antoine Sabot-Durand >>>> <antoine(a)sabot-durand.net&gt;: >>>> Hi guys, >>>> >>>> >>>> So it seems impossible to avoid opt-in on the observer side for the >>>> sake of awkward compatibility. >>>> Adding a member to @Observes could also be a source of issues when >>>> old CDI lib will be used with CDI 2.0 runtime. Some of us (including >>>> me) don¹t want to add an @Async annotation to CDI spec, so perhaps we >>>> should add an async alternative to @Observes with an @AsyncObserves or >>>> @ObservesAsync ? >>>> >>>> So it would be >>>> >>>> public void myObserver(@AsyncObserves payload) {} >>>> >>>> instead of >>>> >>>> @Async >>>> public void myObserver(@Observes payload) {} >>>> >>>> >>>> Pros : >>>> - it¹s a cleaner way to manage the opt-in than to put 2 annotations >>>> or add a member to an existing one >>>> - it could have new members related to async behavior (context >>>> propagation, concurrent scenario, etcŠ) >>>> - As it won¹t be in legacy code no risk to see old observers called >>>> asynchronously >>>> >>>> Cons : >>>> - Still not clear for users when fire() is called to see >>>> @AsyncObserves launched synchronously >>>> - Yet another annotation added >>>> >>>> wdyt ? >>>> >>>> Antoine >>>> >>>> _______________________________________________ >>>> 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. >>> >>> >>> >>> -- >>> Java le soir Cours Java en ligne >>> Twitter Paris JUG Devoxx France >>> M : +33 6 76 82 91 47 >> >> >> >> >> -- >> Java le soir Cours Java en ligne >> Twitter Paris JUG Devoxx France >> M : +33 6 76 82 91 47 >> _______________________________________________ >> 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.

Am 19.03.2015 um 17:19 schrieb Antoine Sabot-Durand <antoine(a)sabot-durand.net&gt;: The killer argument is that nobody succeed to provide a way to prevent opt-in and keep backward compaibility. The problem comes from the fact that producer and consumer can be in different jar compiled with different version of CDI and running on CDI 2.0 preventing using opt-out. If you have the solution without opt-in I’m all ears. > Le 19 mars 2015 à 16:52, José Paumard <jose.paumard(a)gmail.com&gt; a écrit : > > > So it seems impossible to avoid opt-in on the observer side > What is the "killer" argument for that ? > > José > > 2015-03-19 16:44 GMT+01:00 Antoine Sabot-Durand <antoine(a)sabot-durand.net&gt;: > >> Le 19 mars 2015 à 15:51, Romain Manni-Bucau <rmannibucau(a)gmail.com&gt; a écrit : >> >> sounds like a quick and dirty solution to me. @Async will arrive > > Yes like in “Async is coming” ;) > >> - maybe too early today - but adding @ObservesAsync just cause we dont have yet @Async will make this API obselete pretty quickly isn't it (already cause of EJB actually). > > and if we add an @Async in our spec you think it’s better ? > >> >> Do we really want this feature at this price? > > #1 requested feature by users. > >> If yes AsyncObserves sounds an acceptable compromise but still will mess up the API IMO. > > The question is “Is it more or less messy than @Async @Observes?" I don’t know… It has pros and cons as I listed... > >> >> >> Romain Manni-Bucau >> @rmannibucau | Blog | Github | LinkedIn | Tomitriber >> >> 2015-03-19 15:36 GMT+01:00 Antoine Sabot-Durand <antoine(a)sabot-durand.net&gt;: >> Hi guys, >> >> >> So it seems impossible to avoid opt-in on the observer side for the sake of awkward compatibility. >> Adding a member to @Observes could also be a source of issues when old CDI lib will be used with CDI 2.0 runtime. Some of us (including me) don’t want to add an @Async annotation to CDI spec, so perhaps we should add an async alternative to @Observes with an @AsyncObserves or @ObservesAsync ? >> >> So it would be >> >> public void myObserver(@AsyncObserves payload) {} >> >> instead of >> >> @Async >> public void myObserver(@Observes payload) {} >> >> >> Pros : >> - it’s a cleaner way to manage the opt-in than to put 2 annotations or add a member to an existing one >> - it could have new members related to async behavior (context propagation, concurrent scenario, etc…) >> - As it won’t be in legacy code no risk to see old observers called asynchronously >> >> Cons : >> - Still not clear for users when fire() is called to see @AsyncObserves launched synchronously >> - Yet another annotation added >> >> wdyt ? >> >> Antoine >> >> _______________________________________________ >> 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. > > > > -- > Java le soir Cours Java en ligne > Twitter Paris JUG Devoxx France > M : +33 6 76 82 91 47 _______________________________________________ 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.

Le 19 mars 2015 à 22:37, Sven Linstaedt <sven.linstaedt(a)gmail.com&gt; a écrit : Could this opt-in/opt-out problem be defaulted with a new beans.xml version? So older bean archive's observers will be handled synchronously even when the event is triggered asynchronously and the "newer" bean archive's observer will be triggered async, if the caller fired the event async? BR, Sven -- sent by phone Am 19.03.2015 um 17:19 schrieb Antoine Sabot-Durand <antoine(a)sabot-durand.net <mailto:antoine@sabot-durand.net>>: > The killer argument is that nobody succeed to provide a way to prevent opt-in and keep backward compaibility. The problem comes from the fact that producer and consumer can be in different jar compiled with different version of CDI and running on CDI 2.0 preventing using opt-out. > If you have the solution without opt-in I’m all ears. > > >> Le 19 mars 2015 à 16:52, José Paumard <jose.paumard(a)gmail.com <mailto:jose.paumard@gmail.com>> a écrit : >> >> > So it seems impossible to avoid opt-in on the observer side >> What is the "killer" argument for that ? >> >> José >> >> 2015-03-19 16:44 GMT+01:00 Antoine Sabot-Durand <antoine(a)sabot-durand.net <mailto:antoine@sabot-durand.net>>: >> >>> Le 19 mars 2015 à 15:51, Romain Manni-Bucau <rmannibucau(a)gmail.com <mailto:rmannibucau@gmail.com>> a écrit : >>> >>> sounds like a quick and dirty solution to me. @Async will arrive >> >> Yes like in “Async is coming” ;) >> >>> - maybe too early today - but adding @ObservesAsync just cause we dont have yet @Async will make this API obselete pretty quickly isn't it (already cause of EJB actually). >> >> and if we add an @Async in our spec you think it’s better ? >> >>> >>> Do we really want this feature at this price? >> >> #1 requested feature by users. >> >>> If yes AsyncObserves sounds an acceptable compromise but still will mess up the API IMO. >> >> The question is “Is it more or less messy than @Async @Observes?" I don’t know… It has pros and cons as I listed... >> >>> >>> >>> Romain Manni-Bucau >>> @rmannibucau <https://twitter.com/rmannibucau> | Blog <http://rmannibucau.wordpress.com/> | Github <https://github.com/rmannibucau> | LinkedIn <https://www.linkedin.com/in/rmannibucau> | Tomitriber <http://www.tomitribe.com/> >>> 2015-03-19 15:36 GMT+01:00 Antoine Sabot-Durand <antoine(a)sabot-durand.net <mailto:antoine@sabot-durand.net>>: >>> Hi guys, >>> >>> >>> So it seems impossible to avoid opt-in on the observer side for the sake of awkward compatibility. >>> Adding a member to @Observes could also be a source of issues when old CDI lib will be used with CDI 2.0 runtime. Some of us (including me) don’t want to add an @Async annotation to CDI spec, so perhaps we should add an async alternative to @Observes with an @AsyncObserves or @ObservesAsync ? >>> >>> So it would be >>> >>> public void myObserver(@AsyncObserves payload) {} >>> >>> instead of >>> >>> @Async >>> public void myObserver(@Observes payload) {} >>> >>> >>> Pros : >>> - it’s a cleaner way to manage the opt-in than to put 2 annotations or add a member to an existing one >>> - it could have new members related to async behavior (context propagation, concurrent scenario, etc…) >>> - As it won’t be in legacy code no risk to see old observers called asynchronously >>> >>> Cons : >>> - Still not clear for users when fire() is called to see @AsyncObserves launched synchronously >>> - Yet another annotation added >>> >>> wdyt ? >>> >>> Antoine >>> >>> _______________________________________________ >>> cdi-dev mailing list >>> cdi-dev(a)lists.jboss.org <mailto:cdi-dev@lists.jboss.org> >>> https://lists.jboss.org/mailman/listinfo/cdi-dev <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 <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 <mailto:cdi-dev@lists.jboss.org> >> https://lists.jboss.org/mailman/listinfo/cdi-dev <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 <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. >> >> >> >> -- >> Java le soir <http://blog.paumard.org/> Cours Java en ligne <http://blog.paumard.org/cours-tutoriaux/> >> Twitter <http://twitter.com/#!/JosePaumard> Paris JUG <http://www.parisjug.org/> Devoxx France <http://www.devoxx.fr/> >> M : +33 6 76 82 91 47 > > _______________________________________________ > cdi-dev mailing list > cdi-dev(a)lists.jboss.org <mailto:cdi-dev@lists.jboss.org> > https://lists.jboss.org/mailman/listinfo/cdi-dev <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 <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.

On 19 Mar 2015, at 15:54, Romain Manni-Bucau <rmannibucau(a)gmail.com&gt; wrote: 2015-03-19 16:44 GMT+01:00 Antoine Sabot-Durand <antoine(a)sabot-durand.net <mailto:antoine@sabot-durand.net>>: > Le 19 mars 2015 à 15:51, Romain Manni-Bucau <rmannibucau(a)gmail.com <mailto:rmannibucau@gmail.com>> a écrit : > > sounds like a quick and dirty solution to me. @Async will arrive Yes like in “Async is coming” ;) > - maybe too early today - but adding @ObservesAsync just cause we dont have yet @Async will make this API obselete pretty quickly isn't it (already cause of EJB actually). and if we add an @Async in our spec you think it’s better ? no we agree > > Do we really want this feature at this price? #1 requested feature by users. not a reason to mess up the spec IMO. One of the best feature of EE is its stability, here I think we break this basic rule knowing it which doesn't sound professional from my window. This feature is important but already doable today - I guess all vendors provide a solution so business wise you are not blocked and you can even stay portable with very few code (even no code in EE). Other point is defining a more appropriated API is surely needed interacting with the @async/threading spec. EE concurrency spec has something which could help in context propagation if spec is updated: http://docs.oracle.com/javaee/7/api/javax/enterprise/concurrent/ContextSe... <http://docs.oracle.com/javaee/7/api/javax/enterprise/concurrent/ContextSe... can be a way to get context propagation but manually this way it is a "use it at your own risk" solution which is the best can do.

> If yes AsyncObserves sounds an acceptable compromise but still will mess up the API IMO. The question is “Is it more or less messy than @Async @Observes?" I don’t know… It has pros and cons as I listed... agree, both are intermediary states probably which is not satisfying. > > > Romain Manni-Bucau > @rmannibucau <https://twitter.com/rmannibucau> | Blog <http://rmannibucau.wordpress.com/> | Github <https://github.com/rmannibucau> | LinkedIn <https://www.linkedin.com/in/rmannibucau> | Tomitriber <http://www.tomitribe.com/> > 2015-03-19 15:36 GMT+01:00 Antoine Sabot-Durand <antoine(a)sabot-durand.net <mailto:antoine@sabot-durand.net>>: > Hi guys, > > > So it seems impossible to avoid opt-in on the observer side for the sake of awkward compatibility. > Adding a member to @Observes could also be a source of issues when old CDI lib will be used with CDI 2.0 runtime. Some of us (including me) don’t want to add an @Async annotation to CDI spec, so perhaps we should add an async alternative to @Observes with an @AsyncObserves or @ObservesAsync ? > > So it would be > > public void myObserver(@AsyncObserves payload) {} > > instead of > > @Async > public void myObserver(@Observes payload) {} > > > Pros : > - it’s a cleaner way to manage the opt-in than to put 2 annotations or add a member to an existing one > - it could have new members related to async behavior (context propagation, concurrent scenario, etc…) > - As it won’t be in legacy code no risk to see old observers called asynchronously > > Cons : > - Still not clear for users when fire() is called to see @AsyncObserves launched synchronously > - Yet another annotation added > > wdyt ? > > Antoine > > _______________________________________________ > cdi-dev mailing list > cdi-dev(a)lists.jboss.org <mailto:cdi-dev@lists.jboss.org> > https://lists.jboss.org/mailman/listinfo/cdi-dev <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 <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.