[cdi-dev] What about @AsyncObserves ?

Fri Mar 20 10:59:22 EDT 2015

Hi Sven,

We could figure something like that. During last meeting I proposed this (extracted from the log)

17:42:51 <antoine_sd> could we imagine something based on bean archive version
 <>17:43:27 <Jose_P> the question of the contexts should be treated separately imho
 <>17:44:15 <antoine_sd> having async behavior as I proposed only if bean archive are explicitly stated at version 2.x ?
 <>17:44:33 <jharting> that would eliminate implicit bean archives
 <>17:44:52 <antoine_sd> yes I know jharting
 <>17:44:57 <antoine_sd> :-(
 <>17:45:53 <antoine_sd> imagine you have this AsyncSupported member
 <>17:45:58 <antoine_sd> with an enum value
 <>17:46:15 <antoine_sd> auto,true,false
 <>17:46:23 <antoine_sd> default value is at auto
 <>17:46:47 <antoine_sd> if you explictly says that your BA is version 2.0
 <>17:46:49 <antoine_sd> auto is like true
 <>17:46:57 <antoine_sd> if not it's like false
 <>17:47:04 <antoine_sd> and you'll have to opt-in
 <>17:48:00 <antoine_sd> I see you frowning accros the connection jharting  ;)
 <>17:48:51 <antoine_sd> so for implicit BA you'll have to opt-in
 <>17:49:48 <antoine_sd> for explicit BA with version 2.0 you'll have nothing to do to have async (you can still opt-in)
 <>17:50:02 <antoine_sd> and can opt-out for a given observer
 <>17:50:32 <antoine_sd> I'm not sure about the user friendness of this solution ;)
 <>17:51:07 <jharting> it's pretty complicated
 <>17:51:15 <th_janssen> I was just wondering how to explain the different behaviour based on some version number :D
 <>17:51:35 <antoine_sd> I agree

On the paper that could be a good solution, but implicit bean archive add too much complexity here. The only solution would have an easy way to know if a bean archive was compiled with CDI 2.0 API… Having a specific annotation for Async Observer is probably a more standard solution... 

> Le 19 mars 2015 à 22:37, Sven Linstaedt <sven.linstaedt at gmail.com> 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 at sabot-durand.net <mailto:antoine at 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 at gmail.com <mailto:jose.paumard at 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 at sabot-durand.net <mailto:antoine at sabot-durand.net>>:
>>> 
>>>> Le 19 mars 2015 à 15:51, Romain Manni-Bucau <rmannibucau at gmail.com <mailto:rmannibucau at 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 at sabot-durand.net <mailto:antoine at 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 at lists.jboss.org <mailto:cdi-dev at 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 at lists.jboss.org <mailto:cdi-dev at 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 at lists.jboss.org <mailto:cdi-dev at 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.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20150320/d2c75dc7/attachment-0001.html 