<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=""><br class=""><div><blockquote type="cite" class=""><div class="">Le 18 mars 2015 à 10:53, 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=""><div class="gmail_extra"><div class=""><div class="gmail_signature"><div dir="ltr" class=""><div dir="ltr" class=""><div dir="ltr" class=""><div dir="ltr" class=""><br class=""></div></div></div></div></div></div><div class="gmail_quote">2015-03-18 10:33 GMT+01:00 Antoine Sabot-Durand <span dir="ltr" class=""><<a href="mailto:antoine@sabot-durand.net" target="_blank" class="">antoine@sabot-durand.net</a>></span>:<br class=""><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word" class=""><br class=""><div class=""><blockquote type="cite" class=""><div class="">Le 18 mars 2015 à 09:58, Romain Manni-Bucau <<a href="mailto:rmannibucau@gmail.com" target="_blank" class="">rmannibucau@gmail.com</a>> a écrit :</div><span class=""><br class=""><div class=""><div dir="ltr" class=""><div class="gmail_extra"><div class=""><div class=""><div dir="ltr" class=""><div dir="ltr" class=""><div dir="ltr" class=""><div dir="ltr" class=""><br class=""></div></div></div></div></div></div><div class="gmail_quote">2015-03-18 9:55 GMT+01:00 Antoine Sabot-Durand <span dir="ltr" class=""><<a href="mailto:antoine@sabot-durand.net" target="_blank" class="">antoine@sabot-durand.net</a>></span>:<br class=""><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word" class=""><div class=""><blockquote type="cite" class=""><div class=""><br class="">Le 18 mars 2015 à 09:42, Romain Manni-Bucau <<a href="mailto:rmannibucau@gmail.com" target="_blank" class="">rmannibucau@gmail.com</a>> a écrit :</div><span class=""><br class=""><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></span></blockquote><div class=""><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><span class=""><div class=""><br class=""></div></span></div></div></blockquote><div class=""><br class=""></div><div class="">+1</div><div class=""> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word" class=""><div class=""><span class=""><div 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 class=""><br class=""></div></span><div class="">@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><div class=""><div class=""><br class=""></div></div></div></div></blockquote><div class=""><br class=""></div><div class="">don't get it, observer can use j8 then to do its stuff asynchronously so maybe the feature if finally useless assuming you run on j8.</div></div></div></div></div></span></blockquote><div class=""><br class=""></div><div class="">And how do you make your fire point know that one of its observer will be asynchronous ? How do you manage event ordering (as we plan to support it for async event as well). I think we shouldn’t see the event bus as a standard method call but something more featured (think about parameter injection in observer methods or transactional behavior)</div><span class=""><br class=""></span></div></div></blockquote><div class=""><br class=""></div><div class="">then this is not asynchronism and just an observer queue which is something different IMO.</div></div></div></div></div></blockquote><div><br class=""></div><div>From user pov it’s async : "I fire an event and get the control back right away". The impl will make an observer queue in an other thread, but the user exp is totally different than classic fire().</div><br class=""><blockquote type="cite" class=""><div class=""><div dir="ltr" class=""><div class="gmail_extra"><div class="gmail_quote"><div class=""> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word" class=""><div class=""><span class=""><blockquote type="cite" class=""><div class=""><div dir="ltr" class=""><div class="gmail_extra"><div class="gmail_quote"><div class=""><br class=""></div><div class="">That said saying a method is async is still more elegant than firing it in a pool you don't control.</div></div></div></div></div></blockquote><div class=""><br class=""></div></span><div class="">fireAsync will have a signature allowing you to pass your own Executor to give you better control on thread pool</div><div class=""><div class="h5"><br class=""></div></div></div></div></blockquote><div class=""><br class=""></div><div class="">a default one should be bound to the bm - main case IMO. having an app executor is not a very nice solution in term of API. </div></div></div></div></div></blockquote><div><br class=""></div><div>Yes it was already discussed, there will be 2 signatures for fireAsync().</div><div><br class=""></div><div><br class=""></div><br class=""><blockquote type="cite" class=""><div class=""><div dir="ltr" class=""><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word" class=""><div class=""><div class=""><div class="h5"><blockquote type="cite" class=""><div class=""><div dir="ltr" class=""><div class="gmail_extra"><div class="gmail_quote"><div class=""> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word" class=""><div class=""><div class=""><div 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=""><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=""><div class=""><<a href="mailto:antoine@sabot-durand.net" target="_blank" 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" target="_blank" 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" target="_blank" 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=""><div class="">_______________________________________________<br class="">
cdi-dev mailing list<br class="">
<a href="mailto:cdi-dev@lists.jboss.org" target="_blank" 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></div></div><br class=""></div></blockquote></div><br class=""></div></div>
</div></blockquote></div></div></div><br class=""></div></blockquote></div><br class=""></div></div>
</div></blockquote></div><br class=""></body></html>