[cdi-dev] On @Observes for async events

[Jozef Hartinger]

On 03/18/2015 01:46 PM, Romain Manni-Bucau wrote:
>
> 2015-03-18 13:35 GMT+01:00 Jozef Hartinger <jharting at redhat.com 
> <mailto: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
>>     <mailto: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
Well, the thread firing an event won't wait for the observers to 
complete so I cannot see how it breaks your "original async need/wish". 
Or do you associate "async" with splitting the work into as many 
parallel threads as possible? If so then we have a mismatch in terminology.
>
>>
>>             (+ 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
Which part is not aligned? In the current proposal you get a callback 
when all observers complete or an exception occurs. In what order the 
observers are called does not change anything about that.
>
>>     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/5cb28c06/attachment-0001.html