[cdi-dev] On @Observes for async events

[Romain Manni-Bucau]

2015-03-18 13:35 GMT+01:00 Jozef Hartinger <jharting at redhat.com>:

>
> On 03/18/2015 01:28 PM, Romain Manni-Bucau wrote:
>
>
>
> 2015-03-18 13:15 GMT+01:00 Jozef Hartinger <jharting at redhat.com>:
>
>>
>> On 03/18/2015 11:16 AM, Romain Manni-Bucau wrote:
>>
>>> sequentializing them arbitrarily just makes it not async anymore
>>>
>>  the event firing thread won't wait for event delivery so it is still
>> async
>
>
>  well doesn't change the fact you break original async need/wish doing it.
>
> break what?
>
>   don't wait behavior, own thread model by call which is what async means
most of the time


>
>
>>
>>  (+ think to the case you dont really have priorities you are just
>>> breaking the whole concept).
>>>
>>  If you do not have priorities (or they are the same) then it is most
>> likely fine to notify the observers in parallel. If you however do have
>> priorities then it makes sense IMO to take them into account. Doing
>> otherwise just complicates the entire concept by adding an artificial
>> constraint.
>>
>
>
>  point is you are introducing a model concept which is not aligned on the
> common model + doesn't even match correctly the async needs (what about
> onFailure() and onTimeout() which are mandatory when doing async)
>
> what common model?
>
>
> callbacks one which is the only one making async usable and prod compatible

>  I tend to join Mark saying we should just do the minimum instead of
> wanting to do to much and providing something highly broken we'll need to
> fix in next version with more broken patterns. What's the need is the real
> question, not what would be cool to implement.
>
>  Don't forget an async spec smells more and more strong with real async
> semantic and solutions so I guess the less we put in CDI now better it is.
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20150318/11a02ce1/attachment.html