Not sure how alias works, so resending directly. Responses inline.
The bottom line is that we should think about the usability of the most common end user.
If anyone needs custom executor service control in the worst case it's still just a
matter of one extra parameter as opposed to introducing an obscure alternative to
CompletableFuture.
On Mar 7, 2016, at 4:38 PM, Reza Rahman <reza_rahman(a)lycos.com>
wrote:
Responses in-line.
Sent from my iPhone
> On Mar 7, 2016, at 4:24 PM, Romain Manni-Bucau <rmannibucau(a)gmail.com> wrote:
>
>
> 2016-03-07 22:09 GMT+01:00 Reza Rahman <reza_rahman(a)lycos.com>:
>> Responses in-line.
>>
>>> On Mar 7, 2016, at 3:35 PM, Romain Manni-Bucau <rmannibucau(a)gmail.com>
wrote:
>>>
>>>
>>> 2016-03-07 20:53 GMT+01:00 Reza Rahman <reza_rahman(a)lycos.com>:
>>>> Yes, this can be done with a CompletableFuture that has already been
constructed - just take a look at the API.
>>>
>>> so - just to try to ensure we speak about the same thing:
>>>
>>> asyncEvent.fireAsync(...).thenRunAsync(() -> ..., eePool); ?
>>
>> Correct.
>>
>>>
>>> This works but has the drawback to not reuse the observer thread
>>
>> Why would this matter to the average business code developer? All this would run
from managed executors of some kind or the other anyway...
>>
>>> and keep the original issue: the observer doesn't inherit from the caller
context so it would likely be:
>>>
>>> asyncEvent.fireAsync(..., eePool).thenRunAsync(() -> ..., eePool);
>>
>> Again, why does it matter really? The observer threads themselves should be
running from a managed pool that is smart enough to preserve context anyway? If the
business developer cares about preserving context in their code, they can use a managed
executor themselves on the returned CompletableFuture.
>
> Cause it is important to state which thread context is there to keep the integration
with other frameworks - think to security ones in particualr - smooth and doable.
For framework developers usability is hardly a concern. If they need to preserve their
own context they can simply pass in their own managed executor to both the observer thread
and the CompletableFuture.
In the end, the primary focus should be the masses that we hope will adopt CDI into their
applications. Making things harder for them to achieve some limited SPI goal is pretty
dangerous.
>>>
>>> which looks weird since you trigger 2 tasks where you actually want just one
in another thread originally?
>>
>> I don't follow. Whichever executor service you would use, ultimately there
are at least three different threads associated here in all cases.
>>
>>>
>>> asyncEvent.fireAsync(..., eePool).thenRunAsync(() -> ...); // in the fire
async thread
>>
>> You mean using the same executor? Why does this matter really? They are all
managed executors anyway. At best it's reducing one method parameter.
>
> Cause very few apps are 100% EE in practise, probably never will be and even if so
JavaEE security is not integrated (yet?) at this level.
There is no such thing as context propagation outside of EE managed executors. In SE
land, the only thing you have is manually writing your own executor to do the same things.
These folks will have to pass around their own executors anyway, even to the observer
thread.
>>> Are
>>> 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.
>>>
>>>> As far as not adding it to CDI, I can see either way. What was the
original motivation for adding CompletableFutures?
>>>>
>>>> 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.
>>>>
>>>>> On Mar 7, 2016, at 2:39 PM, Romain Manni-Bucau
<rmannibucau(a)gmail.com> wrote:
>>>>>
>>>>>
>>>>> 2016-03-07 20:35 GMT+01:00 Reza Rahman
<reza_rahman(a)lycos.com>:
>>>>>> 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.
>>>>>>
>>>>>> Basically this means CompletableFutures are already pretty Java
EE ready.
>>>>>>
>>>>>> 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?
>>>>>
>>>>> 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*.
>>>>>
>>>>>>> On Mar 7, 2016, at 8:11 AM, Reza Rahman
<reza_rahman(a)lycos.com> wrote:
>>>>>>>
>>>>>>> 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.
>>>>>>>
>>>>>>>> On Mar 7, 2016, at 3:45 AM, Romain Manni-Bucau
<rmannibucau(a)gmail.com> wrote:
>>>>>>>>
>>>>>>>> 2016-03-07 9:07 GMT+01:00 Martin Kouba
<mkouba(a)redhat.com>:
>>>>>>>>>
>>>>>>>>> Dne 7.3.2016 v 09:03 Romain Manni-Bucau napsal(a):
>>>>>>>>>>
>>>>>>>>>> Le 7 mars 2016 08:35, "Martin Kouba"
<mkouba(a)redhat.com
>>>>>>>>>> <mailto:mkouba@redhat.com>> a écrit :
>>>>>>>>>> >
>>>>>>>>>> > Dne 6.3.2016 v 15:39 Romain Manni-Bucau
napsal(a):
>>>>>>>>>> >
>>>>>>>>>> >> Hi guys,
>>>>>>>>>> >>
>>>>>>>>>> >> as a user having a ComlpetionStage
makes me loose some JDK utilities,
>>>>>>>>>> >> can we move back to CompletionFuture?
>>>>>>>>>> >>
>>>>>>>>>> >> It would allow for instance:
>>>>>>>>>> >>
>>>>>>>>>> >> // doesn't work with
CompletionStage
>>>>>>>>>> >>
CompletionFuture.allOf(event1.fireAsync(...), event2.fireAsync(...))
>>>>>>>>>> >> .then(...)
>>>>>>>>>> >
>>>>>>>>>> >
>>>>>>>>>> > Well, this should work if the underlying
CompletionStage impl
>>>>>>>>>> supports toCompletableFuture(), i.e. in Weld 3:
>>>>>>>>>> >
>>>>>>>>>>
>>>>>>>>>> Yes but it is not natural to convert it IMO = we
can do better
>>>>>>>>>>
>>>>>>>>>> >
CompletableFuture.allOf(event1.fireAsync(...).toCompletableFuture(),
>>>>>>>>>> event2.fireAsync(...).toCompletableFuture())
>>>>>>>>>> >
>>>>>>>>>> > AFAIK the default async execution facility
of CompletableFuture is
>>>>>>>>>> ForkJoinPool.commonPool() which is not a good fit
for Java EE. Using the
>>>>>>>>>> CompletionStage interface allows us to wrap the
async calls without the
>>>>>>>>>> specified executor (e.g.
CompletionStage.thenApplyAsync(Function<? super
>>>>>>>>>> T, ? extends U>)) and supply a default one
provided by the impl.
>>>>>>>>>> >
>>>>>>>>>>
>>>>>>>>>> Should use the pool in which the evznt is fired
then "then step" is
>>>>>>>>>> synchronous is my sample so all is decided at
fire time
>>>>>>>>>
>>>>>>>>> I don't talk about your particular example - I
understand that it's not using async exec (although the "then()" method does
not exist).
>>>>>>>>
>>>>>>>> was supposed to represent the different flavours
(thenRun, thenCompose, ...) ;).
>>>>>>>>
>>>>>>>> That said I agree on the state switching the pool is
better but with these 2 notes:
>>>>>>>>
>>>>>>>> - 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
>>>>>>>> - 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)
>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> >
>>>>>>>>>> >>
>>>>>>>>>> >> Romain Manni-Bucau
>>>>>>>>>> >> @rmannibucau
<
https://twitter.com/rmannibucau> | Blog
>>>>>>>>>> >>
<
http://rmannibucau.wordpress.com> | Github
>>>>>>>>>> >> <
https://github.com/rmannibucau>
| LinkedIn
>>>>>>>>>> >>
<
https://www.linkedin.com/in/rmannibucau> | Tomitriber
>>>>>>>>>> >> <
http://www.tomitribe.com>
>>>>>>>>>> >>
>>>>>>>>>> >>
>>>>>>>>>> >>
>>>>>>>>>> >>
_______________________________________________
>>>>>>>>>> >> cdi-dev mailing list
>>>>>>>>>> >> cdi-dev(a)lists.jboss.org
<mailto:cdi-dev@lists.jboss.org>
>>>>>>>>>> >>
https://lists.jboss.org/mailman/listinfo/cdi-dev
>>>>>>>>>> >>
>>>>>>>>>> >> Note that for all code provided on this
list, the provider licenses
>>>>>>>>>> the code under the Apache License, Version 2
>>>>>>>>>>
(
http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas
>>>>>>>>>> provided on this list, the provider waives all
patent and other
>>>>>>>>>> intellectual property rights inherent in such
information.
>>>>>>>>>> >>
>>>>>>>>>> >
>>>>>>>>>> > --
>>>>>>>>>> > Martin Kouba
>>>>>>>>>> > Software Engineer
>>>>>>>>>> > Red Hat, Czech Republic
>>>>>>>>>
>>>>>>>>> --
>>>>>>>>> Martin Kouba
>>>>>>>>> Software Engineer
>>>>>>>>> Red Hat, Czech Republic
>>>>>>>>
>>>>>>>> _______________________________________________
>>>>>>>> cdi-dev mailing list
>>>>>>>> cdi-dev(a)lists.jboss.org
>>>>>>>>
https://lists.jboss.org/mailman/listinfo/cdi-dev
>>>>>>>>
>>>>>>>> Note that for all code provided on this list, the
provider licenses the code under the Apache License, Version 2
(
http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas provided on this
list, the provider waives all patent and other intellectual property rights inherent in
such information.
>>>>>>
>>>>>> _______________________________________________
>>>>>> cdi-dev mailing list
>>>>>> cdi-dev(a)lists.jboss.org
>>>>>>
https://lists.jboss.org/mailman/listinfo/cdi-dev
>>>>>>
>>>>>> Note that for all code provided on this list, the provider
licenses the code under the Apache License, Version 2
(
http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas provided on this
list, the provider waives all patent and other intellectual property rights inherent in
such information.
>>>>
>>>> _______________________________________________
>>>> cdi-dev mailing list
>>>> cdi-dev(a)lists.jboss.org
>>>>
https://lists.jboss.org/mailman/listinfo/cdi-dev
>>>>
>>>> Note that for all code provided on this list, the provider licenses the
code under the Apache License, Version 2
(
http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas provided on this
list, the provider waives all patent and other intellectual property rights inherent in
such information.
>>
>> _______________________________________________
>> cdi-dev mailing list
>> cdi-dev(a)lists.jboss.org
>>
https://lists.jboss.org/mailman/listinfo/cdi-dev
>>
>> Note that for all code provided on this list, the provider licenses the code
under the Apache License, Version 2 (
http://www.apache.org/licenses/LICENSE-2.0.html). For
all other ideas provided on this list, the provider waives all patent and other
intellectual property rights inherent in such information.
>