[cdi-dev] What about @AsyncObserves ?

Fri Mar 20 02:55:56 EDT 2015

Depends on what we like to achieve with this feature.

Imo it’s simple as that: there are cases where the observer MUST get executed on the same thread. There might be @RequestScoped beans, TX and even native ThreadLocals involved. And the sender doesn’t always know. 

In practice this would mean that you can only use fireAsync if you know ALL your observers. But this totally defeats most of the benefits of an eventing pattern. So people will simply not use fireAsync most of the time (as defensive approach).

LieGrue,
strub

> Am 19.03.2015 um 21:04 schrieb Jens Schumann <jens.schumann at openknowledge.de>:
> 
> 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 at yahoo.de>:
> 
>> 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 at gmail.com>:
>>> 
>>> 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 |  Blog | Github | LinkedIn | Tomitriber
>>>>> 
>>>>> 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 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 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.
> 