[cdi-dev] What about @AsyncObserves ?

Thu Mar 19 16:04:08 EDT 2015

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.