[cdi-dev] On @Observes for async events

[Arne Limburg]

Hi Antoine,

The third bullet point in 10.5.1 of the CDI 1.1 spec states that the
observer method must be called in the same transaction context as the
event.fire(...) if it is no transactional observer (that is
TransactionPhase.IN_PROGRESS).
If the default behavior would be async, we would have to move the
transaction context to another thread. To my best knowledge this would be
the only situation in EE where this is the case.

Cheers,
Arne

Am 18.03.15 09:21 schrieb "Antoine Sabot-Durand" unter
<antoine at sabot-durand.net>:

>Hi Arne,
>
>Sorry can you explain why? This value allows observer to be called inside
>or outside a transaction. What will be the compatibility issue?
>
>Antoine
>
>
>> Le 18 mars 2015 à 09:05, Arne Limburg <arne.limburg at openknowledge.de> a
>>écrit :
>> 
>> Hi to all,
>> 
>> I think the biggest issue with backward compatibility is, that the
>>current
>> @Observes annotation by default has TransactionPhase.IN_PROGRESS.
>> I think we can¹t deal with this, if the default for observers would be
>> async. So I think there is no way to specify async as default without
>> loosing backward compatibility.
>> Any other thoughts?
>> 
>> Cheers,
>> Arne
>> 
>> 
>> Am 18.03.15 08:48 schrieb "Antoine Sabot-Durand" unter
>> <antoine at sabot-durand.net>:
>> 
>>> Hi all,
>>> 
>>> Yesterday we had another meeting to try to find a better solution than
>>> explicitly activating async event on observer, without no success. I
>>> understand that we should go on on this feature so what I suggest is to
>>> have a meeting (an hangout) with people that want to try to find a
>>>better
>>> solution. If we find something we¹ll do a last proposal, and in all
>>>case
>>> we¹ll adopt the woking solution next week for this point. People
>>> interested with this please manifest yourself.
>>> 
>>> If we have to go with opt-in (have to explicitly declare an observer
>>> supporting async event) we also have to validate the decision to use a
>>> member in @Observes (as it was decided before) or go back on that as
>>> mMark keep asking by introducing a new annotation to add on the
>>>observer
>>> (@Async or something similar). As I said when we discussed this point,
>>>I
>>> prefer the member in @Observes but we may have overlooked issues linked
>>> to backward compatibility.
>>> A third solution might be to introduce an @ObserveAsync to declare an
>>> asynchronous capable observerŠ
>>> 
>>> I¹m waiting for active feedback from you to find the best solution
>>>taking
>>> ALL aspects (not only the technicals one) into account.
>>> 
>>> Thanks,
>>> 
>>> Antoine
>> 
>