<div dir="ltr"><div class="gmail_extra"><div><div class="gmail_signature"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr">2016-03-07 14:15 GMT+01:00 Reza Rahman <span dir="ltr">&lt;<a href="mailto:reza_rahman@lycos.com" target="_blank">reza_rahman@lycos.com</a>&gt;</span>:<br></div></div></div></div></div></div><div class="gmail_quote"><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>I am really confused now. Why shouldn&#39;t Java EE concurrency not be able to define a standard way to configure custom executors? You can do that today, just in vendor specific ways...</div><div><div class="h5"><div><br></div></div></div></div></blockquote><div><br></div><div>Cause there are several libs where you don&#39;t control the pool and the best you can do is to wrap the task (Runnable) on your side. Also you can hit it in background threads you can&#39;t enforce to use concurrency spec and finally you can hit it in fully synchronous way if you execute after the CDI chain - which is allowed by CDI and TCK-ed so you can need a way to stack the context to reuse some part after. Last &quot;?&quot;: JTA integration: you can also hit it to save data after @TransactionScoped for audit purposes.</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 class="h5"><div>On Mar 7, 2016, at 5:10 AM, Romain Manni-Bucau &lt;<a href="mailto:rmannibucau@gmail.com" target="_blank">rmannibucau@gmail.com</a>&gt; 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 10:57 GMT+01:00 Martin Kouba <span dir="ltr">&lt;<a href="mailto:mkouba@redhat.com" target="_blank">mkouba@redhat.com</a>&gt;</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">Dne 7.3.2016 v 09:45 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>
2016-03-07 9:07 GMT+01:00 Martin Kouba &lt;<a href="mailto:mkouba@redhat.com" target="_blank">mkouba@redhat.com</a><br></span>
&lt;mailto:<a href="mailto:mkouba@redhat.com" target="_blank">mkouba@redhat.com</a>&gt;&gt;:<span><br>
<br>
<br>
    Dne 7.3.2016 v 09:03 Romain Manni-Bucau napsal(a):<br>
<br>
<br>
        Le 7 mars 2016 08:35, &quot;Martin Kouba&quot; &lt;<a href="mailto:mkouba@redhat.com" target="_blank">mkouba@redhat.com</a><br>
        &lt;mailto:<a href="mailto:mkouba@redhat.com" target="_blank">mkouba@redhat.com</a>&gt;<br></span>
        &lt;mailto:<a href="mailto:mkouba@redhat.com" target="_blank">mkouba@redhat.com</a> &lt;mailto:<a href="mailto:mkouba@redhat.com" target="_blank">mkouba@redhat.com</a>&gt;&gt;&gt; a écrit :<div><div><br>
          &gt;<br>
          &gt; Dne 6.3.2016 v 15:39 Romain Manni-Bucau napsal(a):<br>
          &gt;<br>
          &gt;&gt; Hi guys,<br>
          &gt;&gt;<br>
          &gt;&gt; as a user having a ComlpetionStage makes me loose some JDK<br>
        utilities,<br>
          &gt;&gt; can we move back to CompletionFuture?<br>
          &gt;&gt;<br>
          &gt;&gt; It would allow for instance:<br>
          &gt;&gt;<br>
          &gt;&gt; // doesn&#39;t work with CompletionStage<br>
          &gt;&gt; CompletionFuture.allOf(event1.fireAsync(...),<br>
        event2.fireAsync(...))<br>
          &gt;&gt;        .then(...)<br>
          &gt;<br>
          &gt;<br>
          &gt; Well, this should work if the underlying CompletionStage impl<br>
        supports toCompletableFuture(), i.e. in Weld 3:<br>
          &gt;<br>
<br>
        Yes but it is not natural to convert it IMO = we can do better<br>
<br>
          &gt;<br>
        CompletableFuture.allOf(event1.fireAsync(...).toCompletableFuture(),<br>
        event2.fireAsync(...).toCompletableFuture())<br>
          &gt;<br>
          &gt; AFAIK the default async execution facility of<br>
        CompletableFuture is<br>
        ForkJoinPool.commonPool() which is not a good fit for Java EE.<br>
        Using the<br>
        CompletionStage interface allows us to wrap the async calls<br>
        without the<br>
        specified executor (e.g.<br>
        CompletionStage.thenApplyAsync(Function&lt;? super<br>
        T, ? extends U&gt;)) and supply a default one provided by the impl.<br>
          &gt;<br>
<br>
        Should use the pool in which the evznt is fired then &quot;then step&quot; is<br>
        synchronous is my sample so all is decided at fire time<br>
<br>
<br>
    I don&#39;t talk about your particular example - I understand that it&#39;s<br>
    not using async exec (although the &quot;then()&quot; method does not exist).<br>
<br>
<br>
was supposed to represent the different flavours (thenRun, thenCompose,<br>
...) ;).<br>
<br>
That said I agree on the state switching the pool is better but with<br>
these 2 notes:<br>
<br>
- could be better to hide these poorly designed methods then -&gt; don&#39;t<br>
use CompletionXXX but a CDI API with a bridge to CompletionX to let the<br>
user go back on SE tools<br>
</div></div></blockquote>
<br>
Yep, this is one of the possible solutions. On the other hand, I don&#39;t think it&#39;s poorly designed. CompletionStage defines the &quot;default asynchronous execution facility&quot; and CDI spec states that the CompletionStage returned by fireAsync methods is container-specific. The impl may choose to clarify this &quot;default asynchronous execution facility&quot;, i.e. there&#39;s place for innovation...<span><br>
<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">
- we still don&#39;t have a *standard* config for the pool(s) underlying CDI<br>
features so it sounds as poor as SE solution IMO (at least a<br>
core/max/ttl config in beans.xml)<br>
</blockquote>
<br></span>
I don&#39;t think this should be standardized...<br>
<br></blockquote><div><br></div><div>Why? Typically if you take @Asynchronous (EJB spec) you have already this issue and this is often avoided when portability matters for that particular reason you don&#39;t know how you will behave. Or do you think concurrency-utilities solves it?</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>
          &gt;<br>
          &gt;&gt;<br>
          &gt;&gt; Romain Manni-Bucau<br>
          &gt;&gt; @rmannibucau &lt;<a href="https://twitter.com/rmannibucau" rel="noreferrer" target="_blank">https://twitter.com/rmannibucau</a>&gt; | Blog<br>
          &gt;&gt; &lt;<a href="http://rmannibucau.wordpress.com" rel="noreferrer" target="_blank">http://rmannibucau.wordpress.com</a>&gt; | Github<br>
          &gt;&gt; &lt;<a href="https://github.com/rmannibucau" rel="noreferrer" target="_blank">https://github.com/rmannibucau</a>&gt; | LinkedIn<br>
          &gt;&gt; &lt;<a href="https://www.linkedin.com/in/rmannibucau" rel="noreferrer" target="_blank">https://www.linkedin.com/in/rmannibucau</a>&gt; | Tomitriber<br>
          &gt;&gt; &lt;<a href="http://www.tomitribe.com" rel="noreferrer" target="_blank">http://www.tomitribe.com</a>&gt;<br>
          &gt;&gt;<br>
          &gt;&gt;<br>
          &gt;&gt;<br>
          &gt;&gt; _______________________________________________<br>
          &gt;&gt; cdi-dev mailing list<br>
          &gt;&gt; <a href="mailto:cdi-dev@lists.jboss.org" target="_blank">cdi-dev@lists.jboss.org</a> &lt;mailto:<a href="mailto:cdi-dev@lists.jboss.org" target="_blank">cdi-dev@lists.jboss.org</a>&gt;<br></span>
        &lt;mailto:<a href="mailto:cdi-dev@lists.jboss.org" target="_blank">cdi-dev@lists.jboss.org</a> &lt;mailto:<a href="mailto:cdi-dev@lists.jboss.org" target="_blank">cdi-dev@lists.jboss.org</a>&gt;&gt;<span><br>
          &gt;&gt; <a href="https://lists.jboss.org/mailman/listinfo/cdi-dev" rel="noreferrer" target="_blank">https://lists.jboss.org/mailman/listinfo/cdi-dev</a><br>
          &gt;&gt;<br>
          &gt;&gt; Note that for all code provided on this list, the provider<br>
        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<br>
        ideas<br>
        provided on this list, the provider waives all patent and other<br>
        intellectual property rights inherent in such information.<br>
          &gt;&gt;<br>
          &gt;<br>
          &gt; --<br>
          &gt; Martin Kouba<br>
          &gt; Software Engineer<br>
          &gt; Red Hat, Czech Republic<br>
<br>
<br>
    --<br>
    Martin Kouba<br>
    Software Engineer<br>
    Red Hat, Czech Republic<br>
<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></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>