[cdi-dev] What about @AsyncObserves ?

[José Paumard]

> 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>:

>
> Le 19 mars 2015 à 15:51, Romain Manni-Bucau <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>
> :
>
>> 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
>> 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 at 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 <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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20150319/db4f05c6/attachment.html