<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">2016-03-07 20:53 GMT+01:00 Reza Rahman <span dir="ltr"><<a href="mailto:reza_rahman@lycos.com" target="_blank">reza_rahman@lycos.com</a>></span>:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="auto"><div>Yes, this can be done with a CompletableFuture that has already been constructed - just take a look at the API.</div><div><br></div></div></blockquote><div><br></div><div>so - just to try to ensure we speak about the same thing:</div><div><br></div><div>asyncEvent.fireAsync(...).thenRunAsync(() -> ..., eePool); ?</div><div><br></div><div>This works but has the drawback to not reuse the observer thread and keep the original issue: the observer doesn't inherit from the caller context so it would likely be:</div><div><br></div><div>asyncEvent.fireAsync(..., eePool).thenRunAsync(() -> ..., eePool);</div><div><br></div><div>which looks weird since you trigger 2 tasks where you actually want just one in another thread originally?</div><div><br></div><div>asyncEvent.fireAsync(..., eePool).thenRunAsync(() -> ...); // in the fire async thread<br></div><div><br></div><div>This last proposal works not that bad if context propagation would work but since there are cases it would be expected to work and other it shouldn't - from a user point of view auto inheritance can break thread safety - I wonder if it shouldn't be spec-ed. Can be the new API I proposed or even just a new scope close to request scoped but inheritable by design.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="auto"><div></div><div>As far as not adding it to CDI, I can see either way. What was the original motivation for adding CompletableFutures?</div><div><br></div><div>Also, it's a good idea to run this by the platform expert group. I know at least JAX-RS is planning to use CompletableFutures for their client API.</div><div><div class="h5"><div><br>On Mar 7, 2016, at 2:39 PM, Romain Manni-Bucau <<a href="mailto:rmannibucau@gmail.com" target="_blank">rmannibucau@gmail.com</a>> wrote:<br><br></div><blockquote type="cite"><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">2016-03-07 20:35 GMT+01:00 Reza Rahman <span dir="ltr"><<a href="mailto:reza_rahman@lycos.com" target="_blank">reza_rahman@lycos.com</a>></span>:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="auto"><div>Talking with a colleague about this he reminded me of an important fact I almost forgot. The CompletableFuture API can actually be used with custom executors. That means users concerned about managed threads in a Java EE environment can use it with existing EE 7 concurrency executors.</div><div><br></div><div>Basically this means CompletableFutures are already pretty Java EE ready.</div><div><br></div><div>If this is the main cited reason for using CompletionStage, is it really that valid of an argument to justify yet another custom subclass specific only to CDI instead of what's likely to be far more familiar and expected?</div><div><div><div><br></div></div></div></div></blockquote><div><br></div><div>Did he mention it is true for *created* comlpetion future which is not the case for async events? But this is a good point to not add anything to CDI: the feature is a one liner *already*.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="auto"><div><div><div>On Mar 7, 2016, at 8:11 AM, Reza Rahman <<a href="mailto:reza_rahman@lycos.com" target="_blank">reza_rahman@lycos.com</a>> wrote:<br><br></div><blockquote type="cite"><div><div>I think this is a very bad idea. It's better not to use either API and wait to sort out how CompletableFuture can be used in EE consistently. Because of backwards compatibility rules, it is better to have no API than a bad API.</div><div><br>On Mar 7, 2016, at 3:45 AM, Romain Manni-Bucau <<a href="mailto:rmannibucau@gmail.com" target="_blank">rmannibucau@gmail.com</a>> wrote:<br><br></div><blockquote type="cite"><div><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">2016-03-07 9:07 GMT+01:00 Martin Kouba <span dir="ltr"><<a href="mailto:mkouba@redhat.com" target="_blank">mkouba@redhat.com</a>></span>:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><br>
Dne 7.3.2016 v 09:03 Romain Manni-Bucau napsal(a):<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><span>
<br>
Le 7 mars 2016 08:35, "Martin Kouba" <<a href="mailto:mkouba@redhat.com" target="_blank">mkouba@redhat.com</a><br></span>
<mailto:<a href="mailto:mkouba@redhat.com" target="_blank">mkouba@redhat.com</a>>> a écrit :<span><br>
><br>
> Dne 6.3.2016 v 15:39 Romain Manni-Bucau napsal(a):<br>
><br>
>> Hi guys,<br>
>><br>
>> as a user having a ComlpetionStage makes me loose some JDK utilities,<br>
>> can we move back to CompletionFuture?<br>
>><br>
>> It would allow for instance:<br>
>><br>
>> // doesn't work with CompletionStage<br>
>> CompletionFuture.allOf(event1.fireAsync(...), event2.fireAsync(...))<br>
>> .then(...)<br>
><br>
><br>
> Well, this should work if the underlying CompletionStage impl<br>
supports toCompletableFuture(), i.e. in Weld 3:<br>
><br>
<br>
Yes but it is not natural to convert it IMO = we can do better<br>
<br>
> CompletableFuture.allOf(event1.fireAsync(...).toCompletableFuture(),<br>
event2.fireAsync(...).toCompletableFuture())<br>
><br>
> AFAIK the default async execution facility of CompletableFuture is<br>
ForkJoinPool.commonPool() which is not a good fit for Java EE. Using the<br>
CompletionStage interface allows us to wrap the async calls without the<br>
specified executor (e.g. CompletionStage.thenApplyAsync(Function<? super<br>
T, ? extends U>)) and supply a default one provided by the impl.<br>
><br>
<br>
Should use the pool in which the evznt is fired then "then step" is<br>
synchronous is my sample so all is decided at fire time<br>
</span></blockquote>
<br>
I don't talk about your particular example - I understand that it's not using async exec (although the "then()" method does not exist).<br>
<br></blockquote><div><br></div><div>was supposed to represent the different flavours (thenRun, thenCompose, ...) ;).</div><div><br></div><div>That said I agree on the state switching the pool is better but with these 2 notes:</div><div><br></div><div>- could be better to hide these poorly designed methods then -> don't use CompletionXXX but a CDI API with a bridge to CompletionX to let the user go back on SE tools</div><div>- we still don't have a *standard* config for the pool(s) underlying CDI features so it sounds as poor as SE solution IMO (at least a core/max/ttl config in beans.xml)</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><span>
<br>
><br>
>><br>
>> Romain Manni-Bucau<br>
>> @rmannibucau <<a href="https://twitter.com/rmannibucau" rel="noreferrer" target="_blank">https://twitter.com/rmannibucau</a>> | Blog<br>
>> <<a href="http://rmannibucau.wordpress.com" rel="noreferrer" target="_blank">http://rmannibucau.wordpress.com</a>> | Github<br>
>> <<a href="https://github.com/rmannibucau" rel="noreferrer" target="_blank">https://github.com/rmannibucau</a>> | LinkedIn<br>
>> <<a href="https://www.linkedin.com/in/rmannibucau" rel="noreferrer" target="_blank">https://www.linkedin.com/in/rmannibucau</a>> | Tomitriber<br>
>> <<a href="http://www.tomitribe.com" rel="noreferrer" target="_blank">http://www.tomitribe.com</a>><br>
>><br>
>><br>
>><br>
>> _______________________________________________<br>
>> cdi-dev mailing list<br></span>
>> <a href="mailto:cdi-dev@lists.jboss.org" target="_blank">cdi-dev@lists.jboss.org</a> <mailto:<a href="mailto:cdi-dev@lists.jboss.org" target="_blank">cdi-dev@lists.jboss.org</a>><span><br>
>> <a href="https://lists.jboss.org/mailman/listinfo/cdi-dev" rel="noreferrer" 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<br>
the code under the Apache License, Version 2<br>
(<a href="http://www.apache.org/licenses/LICENSE-2.0.html" rel="noreferrer" target="_blank">http://www.apache.org/licenses/LICENSE-2.0.html</a>). For all other ideas<br>
provided on this list, the provider waives all patent and other<br>
intellectual property rights inherent in such information.<br>
>><br>
><br>
> --<br>
> Martin Kouba<br>
> Software Engineer<br>
> Red Hat, Czech Republic<br>
<br>
</span></blockquote><div><div>
<br>
-- <br>
Martin Kouba<br>
Software Engineer<br>
Red Hat, Czech Republic<br>
</div></div></blockquote></div><br></div></div>
</div></blockquote><blockquote type="cite"><div><span>_______________________________________________</span><br><span>cdi-dev mailing list</span><br><span><a href="mailto:cdi-dev@lists.jboss.org" target="_blank">cdi-dev@lists.jboss.org</a></span><br><span><a href="https://lists.jboss.org/mailman/listinfo/cdi-dev" target="_blank">https://lists.jboss.org/mailman/listinfo/cdi-dev</a></span><br><span></span><br><span>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.</span></div></blockquote></div></blockquote></div></div></div><br>_______________________________________________<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" rel="noreferrer" 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" rel="noreferrer" 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.<br></blockquote></div><br></div></div>
</div></blockquote></div></div></div><br>_______________________________________________<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" rel="noreferrer" 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" rel="noreferrer" 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.<br></blockquote></div><br></div></div>