<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div><blockquote type="cite" class=""><div class=""><br class="">Le 18 mars 2015 à 09:42, Romain Manni-Bucau <<a href="mailto:rmannibucau@gmail.com" class="">rmannibucau@gmail.com</a>> a écrit :</div><br class="Apple-interchange-newline"><div class=""><div dir="ltr" class="">Hi guys,<div class=""><br class=""></div><div class="">think Mark is right and a new API (as fireAsync) would be better for users for:</div><div class="">- understanding</div><div class="">- compatibility (think to custom extensions using this flag)</div></div></div></blockquote><div><br class=""></div><div class="">My point here is to avoid making CDI the EJB next by introducing @Async or @Asynchronous annotation in the spec. This kind of annotation should be shared by other specs and would have a better fit in concurrency utilities or commons annotations spec.</div><div class=""><br class=""></div><blockquote type="cite" class=""><div class=""><div dir="ltr" class=""><div class="">that said if we have @Async methods I think async observers are really useless, isn't it?</div></div></div></blockquote><div><br class=""></div><div>@Async is rather useless IMO when you see how easy it is do async operation with Java 8. On the other hand Async observers are a at a higher level since they are called thru the Container and that the fire point must know what’s going on at the other side.</div><br class=""><blockquote type="cite" class=""><div class=""><div dir="ltr" class=""><div class=""><br class=""></div></div><div class="gmail_extra"><br clear="all" class=""><div class=""><div class="gmail_signature"><div dir="ltr" class=""><div class=""><div dir="ltr" class=""><div class=""><div dir="ltr" class=""><div class=""><div dir="ltr" class=""><div class=""><br class=""><span style="font-size:small" class="">Romain Manni-Bucau</span><br class=""><a href="https://twitter.com/rmannibucau" target="_blank" class="">@rmannibucau</a> | <a href="http://rmannibucau.wordpress.com/" target="_blank" class="">Blog</a> | <a href="https://github.com/rmannibucau" target="_blank" class="">Github</a> | <a href="https://www.linkedin.com/in/rmannibucau" target="_blank" class="">LinkedIn</a> | <a href="http://www.tomitribe.com/" target="_blank" class="">Tomitriber</a></div></div></div></div></div></div></div></div></div></div>
<br class=""><div class="gmail_quote">2015-03-18 9:30 GMT+01:00 Arne Limburg <span dir="ltr" class=""><<a href="mailto:arne.limburg@openknowledge.de" target="_blank" class="">arne.limburg@openknowledge.de</a>></span>:<br class=""><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi Antoine,<br class="">
<br class="">
The third bullet point in 10.5.1 of the CDI 1.1 spec states that the<br class="">
observer method must be called in the same transaction context as the<br class="">
event.fire(...) if it is no transactional observer (that is<br class="">
TransactionPhase.IN_PROGRESS).<br class="">
If the default behavior would be async, we would have to move the<br class="">
transaction context to another thread. To my best knowledge this would be<br class="">
the only situation in EE where this is the case.<br class="">
<br class="">
Cheers,<br class="">
Arne<br class="">
<br class="">
Am 18.03.15 09:21 schrieb "Antoine Sabot-Durand" unter<br class="">
<div class="HOEnZb"><div class="h5"><<a href="mailto:antoine@sabot-durand.net" class="">antoine@sabot-durand.net</a>>:<br class="">
<br class="">
>Hi Arne,<br class="">
><br class="">
>Sorry can you explain why? This value allows observer to be called inside<br class="">
>or outside a transaction. What will be the compatibility issue?<br class="">
><br class="">
>Antoine<br class="">
><br class="">
><br class="">
>> Le 18 mars 2015 à 09:05, Arne Limburg <<a href="mailto:arne.limburg@openknowledge.de" class="">arne.limburg@openknowledge.de</a>> a<br class="">
>>écrit :<br class="">
>><br class="">
>> Hi to all,<br class="">
>><br class="">
>> I think the biggest issue with backward compatibility is, that the<br class="">
>>current<br class="">
>> @Observes annotation by default has TransactionPhase.IN_PROGRESS.<br class="">
>> I think we can¹t deal with this, if the default for observers would be<br class="">
>> async. So I think there is no way to specify async as default without<br class="">
>> loosing backward compatibility.<br class="">
>> Any other thoughts?<br class="">
>><br class="">
>> Cheers,<br class="">
>> Arne<br class="">
>><br class="">
>><br class="">
>> Am 18.03.15 08:48 schrieb "Antoine Sabot-Durand" unter<br class="">
>> <<a href="mailto:antoine@sabot-durand.net" class="">antoine@sabot-durand.net</a>>:<br class="">
>><br class="">
>>> Hi all,<br class="">
>>><br class="">
>>> Yesterday we had another meeting to try to find a better solution than<br class="">
>>> explicitly activating async event on observer, without no success. I<br class="">
>>> understand that we should go on on this feature so what I suggest is to<br class="">
>>> have a meeting (an hangout) with people that want to try to find a<br class="">
>>>better<br class="">
>>> solution. If we find something we¹ll do a last proposal, and in all<br class="">
>>>case<br class="">
>>> we¹ll adopt the woking solution next week for this point. People<br class="">
>>> interested with this please manifest yourself.<br class="">
>>><br class="">
>>> If we have to go with opt-in (have to explicitly declare an observer<br class="">
>>> supporting async event) we also have to validate the decision to use a<br class="">
>>> member in @Observes (as it was decided before) or go back on that as<br class="">
>>> mMark keep asking by introducing a new annotation to add on the<br class="">
>>>observer<br class="">
>>> (@Async or something similar). As I said when we discussed this point,<br class="">
>>>I<br class="">
>>> prefer the member in @Observes but we may have overlooked issues linked<br class="">
>>> to backward compatibility.<br class="">
>>> A third solution might be to introduce an @ObserveAsync to declare an<br class="">
>>> asynchronous capable observerŠ<br class="">
>>><br class="">
>>> I¹m waiting for active feedback from you to find the best solution<br class="">
>>>taking<br class="">
>>> ALL aspects (not only the technicals one) into account.<br class="">
>>><br class="">
>>> Thanks,<br class="">
>>><br class="">
>>> Antoine<br class="">
>><br class="">
><br class="">
<br class="">
<br class="">
</div></div><div class="HOEnZb"><div class="h5">_______________________________________________<br class="">
cdi-dev mailing list<br class="">
<a href="mailto:cdi-dev@lists.jboss.org" class="">cdi-dev@lists.jboss.org</a><br class="">
<a href="https://lists.jboss.org/mailman/listinfo/cdi-dev" target="_blank" class="">https://lists.jboss.org/mailman/listinfo/cdi-dev</a><br class="">
<br class="">
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" class="">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 class=""></div>
</div></blockquote></div><br class=""></body></html>