<div dir="ltr"><div class="gmail_extra"><div><div class="gmail_signature"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><br></div></div></div></div></div></div><div class="gmail_quote">2015-03-18 10:33 GMT+01:00 Antoine Sabot-Durand <span dir="ltr"><<a href="mailto:antoine@sabot-durand.net" target="_blank">antoine@sabot-durand.net</a>></span>:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word"><br><div><blockquote type="cite"><div>Le 18 mars 2015 à 09:58, Romain Manni-Bucau <<a href="mailto:rmannibucau@gmail.com" target="_blank">rmannibucau@gmail.com</a>> a écrit :</div><span class=""><br><div><div dir="ltr"><div class="gmail_extra"><div><div><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><br></div></div></div></div></div></div><div class="gmail_quote">2015-03-18 9:55 GMT+01:00 Antoine Sabot-Durand <span dir="ltr"><<a href="mailto:antoine@sabot-durand.net" target="_blank">antoine@sabot-durand.net</a>></span>:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word"><div><blockquote type="cite"><div><br>Le 18 mars 2015 à 09:42, Romain Manni-Bucau <<a href="mailto:rmannibucau@gmail.com" target="_blank">rmannibucau@gmail.com</a>> a écrit :</div><span><br><div><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></div></span></blockquote><div><br></div><div>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><div><br></div></span></div></div></blockquote><div><br></div><div>+1</div><div> </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"><div><span><div></div><blockquote type="cite"><div><div dir="ltr"><div>that said if we have @Async methods I think async observers are really useless, isn't it?</div></div></div></blockquote><div><br></div></span><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><div><div><br></div></div></div></div></blockquote><div><br></div><div>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><br></div><div>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></span></div></div></blockquote><div><br></div><div>then this is not asynchronism and just an observer queue which is something different IMO</div><div> </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"><div><span class=""><blockquote type="cite"><div><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div><br></div><div>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><br></div></span><div>fireAsync will have a signature allowing you to pass your own Executor to give you better control on thread pool</div><div><div class="h5"><br></div></div></div></div></blockquote><div><br></div><div>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><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word"><div><div><div class="h5"><blockquote type="cite"><div><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div> </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"><div><div><div><blockquote type="cite"><div><div dir="ltr"><div><br></div></div><div class="gmail_extra"><br clear="all"><div><div><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><div><<a href="mailto:antoine@sabot-durand.net" target="_blank">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" target="_blank">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" target="_blank">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><div>_______________________________________________<br>
cdi-dev mailing list<br>
<a href="mailto:cdi-dev@lists.jboss.org" target="_blank">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>
</div></blockquote></div></div></div><br></div></blockquote></div><br></div></div>
</div></blockquote></div></div></div><br></div></blockquote></div><br></div></div>