[cdi-dev] What about @AsyncObserves ?

[José Paumard]

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


-- 
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/3e53d27e/attachment.html