<div dir="ltr">Hi guys,<div><br></div><div>think Mark is right and a new API (as fireAsync) would be better for users for:</div><div>- understanding</div><div>- compatibility (think to custom extensions using this flag)</div><div><br></div><div>that said if we have @Async methods I think async observers are really useless, isn't it?</div><div><br></div></div><div class="gmail_extra"><br clear="all"><div><div class="gmail_signature"><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr"><div><br><span style="font-size:small">Romain Manni-Bucau</span><br><a href="https://twitter.com/rmannibucau" target="_blank">@rmannibucau</a> | <a href="http://rmannibucau.wordpress.com" target="_blank">Blog</a> | <a href="https://github.com/rmannibucau" target="_blank">Github</a> | <a href="https://www.linkedin.com/in/rmannibucau" target="_blank">LinkedIn</a> | <a href="http://www.tomitribe.com" target="_blank">Tomitriber</a></div></div></div></div></div></div></div></div></div></div>
<br><div class="gmail_quote">2015-03-18 9:30 GMT+01:00 Arne Limburg <span dir="ltr"><<a href="mailto:arne.limburg@openknowledge.de" target="_blank">arne.limburg@openknowledge.de</a>></span>:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi Antoine,<br>
<br>
The third bullet point in 10.5.1 of the CDI 1.1 spec states that the<br>
observer method must be called in the same transaction context as the<br>
event.fire(...) if it is no transactional observer (that is<br>
TransactionPhase.IN_PROGRESS).<br>
If the default behavior would be async, we would have to move the<br>
transaction context to another thread. To my best knowledge this would be<br>
the only situation in EE where this is the case.<br>
<br>
Cheers,<br>
Arne<br>
<br>
Am 18.03.15 09:21 schrieb "Antoine Sabot-Durand" unter<br>
<div class="HOEnZb"><div class="h5"><<a href="mailto:antoine@sabot-durand.net">antoine@sabot-durand.net</a>>:<br>
<br>
>Hi Arne,<br>
><br>
>Sorry can you explain why? This value allows observer to be called inside<br>
>or outside a transaction. What will be the compatibility issue?<br>
><br>
>Antoine<br>
><br>
><br>
>> Le 18 mars 2015 à 09:05, Arne Limburg <<a href="mailto:arne.limburg@openknowledge.de">arne.limburg@openknowledge.de</a>> a<br>
>>écrit :<br>
>><br>
>> Hi to all,<br>
>><br>
>> I think the biggest issue with backward compatibility is, that the<br>
>>current<br>
>> @Observes annotation by default has TransactionPhase.IN_PROGRESS.<br>
>> I think we can¹t deal with this, if the default for observers would be<br>
>> async. So I think there is no way to specify async as default without<br>
>> loosing backward compatibility.<br>
>> Any other thoughts?<br>
>><br>
>> Cheers,<br>
>> Arne<br>
>><br>
>><br>
>> Am 18.03.15 08:48 schrieb "Antoine Sabot-Durand" unter<br>
>> <<a href="mailto:antoine@sabot-durand.net">antoine@sabot-durand.net</a>>:<br>
>><br>
>>> Hi all,<br>
>>><br>
>>> Yesterday we had another meeting to try to find a better solution than<br>
>>> explicitly activating async event on observer, without no success. I<br>
>>> understand that we should go on on this feature so what I suggest is to<br>
>>> have a meeting (an hangout) with people that want to try to find a<br>
>>>better<br>
>>> solution. If we find something we¹ll do a last proposal, and in all<br>
>>>case<br>
>>> we¹ll adopt the woking solution next week for this point. People<br>
>>> interested with this please manifest yourself.<br>
>>><br>
>>> If we have to go with opt-in (have to explicitly declare an observer<br>
>>> supporting async event) we also have to validate the decision to use a<br>
>>> member in @Observes (as it was decided before) or go back on that as<br>
>>> mMark keep asking by introducing a new annotation to add on the<br>
>>>observer<br>
>>> (@Async or something similar). As I said when we discussed this point,<br>
>>>I<br>
>>> prefer the member in @Observes but we may have overlooked issues linked<br>
>>> to backward compatibility.<br>
>>> A third solution might be to introduce an @ObserveAsync to declare an<br>
>>> asynchronous capable observerŠ<br>
>>><br>
>>> I¹m waiting for active feedback from you to find the best solution<br>
>>>taking<br>
>>> ALL aspects (not only the technicals one) into account.<br>
>>><br>
>>> Thanks,<br>
>>><br>
>>> Antoine<br>
>><br>
><br>
<br>
<br>
</div></div><div class="HOEnZb"><div class="h5">_______________________________________________<br>
cdi-dev mailing list<br>
<a href="mailto:cdi-dev@lists.jboss.org">cdi-dev@lists.jboss.org</a><br>
<a href="https://lists.jboss.org/mailman/listinfo/cdi-dev" target="_blank">https://lists.jboss.org/mailman/listinfo/cdi-dev</a><br>
<br>
Note that for all code provided on this list, the provider licenses the code under the Apache License, Version 2 (<a href="http://www.apache.org/licenses/LICENSE-2.0.html" target="_blank">http://www.apache.org/licenses/LICENSE-2.0.html</a>). For all other ideas provided on this list, the provider waives all patent and other intellectual property rights inherent in such information.</div></div></blockquote></div><br></div>