[cdi-dev] async activation on observers, why not CompletableFuture

[Romain Manni-Bucau]

No, fireAsync is still needed for all the reason we mzntionned - strongest
one being the fact we need a return type and cant change fire - but using
the return type we have the double activation without introducing a new
API. Said otherwise API stays natural on both sides which was my main fear
with a fireAsync and an @ObservesAsync (or any other new api we talked
about). And we have the bonus to be aligned on SE async which sounds quite
interesting for the future.
Le 1 avr. 2015 08:48, "Jozef Hartinger" <jharting at redhat.com> a écrit :

>  So instead of calling observers asynchronously you suggest turning
> observers into producers of CompletableFuture that will then be completed
> asynchronously?
>
> On 03/31/2015 06:21 PM, Romain Manni-Bucau wrote:
>
> // fire side
> event.fireAsync(new LetTheWorldKnow()).thenRun(() ->
> System.out.println("We did it!"));
>
>  // observer side
> CompletableFuture iWantToKnow(@Observes LetTheWorldKnow event) {}
>
>  // impl behavior would be like
> CompletableFuture.allOf(allObserverReturnedInstances) to be aligned on
> CompletableFuture behavior I think
>
>  Am I clearer?
>
>
>
> 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>
>
> 2015-03-31 18:15 GMT+02:00 Sven Linstaedt <sven.linstaedt at gmail.com>:
>
>>  Hi Romain,
>>
>>  I am not sure, I have fully understand how an observer with CompletableFuture could
>> look like. Could you give us an example?
>>
>>  Afair CompletableFuture was considered to be used in the "trigger" side
>> in order to track async event invocation completion.
>>
>>  br, Sven
>>
>>  2015-03-31 18:00 GMT+02:00 Romain Manni-Bucau <rmannibucau at gmail.com>:
>>
>>>  Hi guys,
>>>
>>>  on async topic if I followed we are at the point where we are looking
>>> for an activation on the observer side.
>>>
>>>  Since Java 8 has now CompletableFuture it would be great to use it.
>>> Today the spec doesnt use observer returned values so it is mainly a bad
>>> practise to have one even if not strictly forbidden - BTW never saw it in
>>> real applications - plus spec is not compatible - not specified at all -
>>> with CompletableFuture since it is a new API so we can use it as a marker.
>>>
>>>  This is quite interesting for few reasons:
>>> 1- we have our double activation
>>> 2- API is user friendly (observer is async and has an async signature)
>>> 3- open door for future async enhancements (hopefully not in CDI) with
>>> composition of these observers
>>>
>>>
>>>  Only point I'm not sure is should these observers support sync events.
>>> I don't see anything blocking to do it but can have missed something.
>>>
>>>
>>>  wdyt?
>>>
>>>
>>> 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 at 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 listcdi-dev at lists.jboss.orghttps://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.
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20150401/20d2643e/attachment-0001.html