Re: [cdi-dev] What about @AsyncObserves ?

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 &gt;&lt;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 &gt;&gt;&lt;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 &gt;&gt;&gt;&lt;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.