Re: [cdi-dev] Previously on "Double end async events activation"

Hi Antoine, thanks for your input and this summary. I placed my comments inline. Best regards, Mark +1 CDI 2.0 without async events seems a no-go +1 on fireAsync fireAsync triggers always asynchronous event processing. Currently we’re talking about interference between observers, but there are lots of other ways to do nasty things (e.g. modifying the payload from the firing thread). Any caller expects a method returning CompletionStage returning instantly, before any work is done. This leads to the point that disabling async on legacy observers would lead that fireAsync would return after those legacy observers are processed. I would add another case which might help to clarify @Priority as well: 1. fire with @Observers: same behavior as CDI 1.x 2. fireAsync with @Observes: observers are processed in any order in sequence but in a different thread - nothing new until now - 3. fireAsync with @Observers and @Concurrent (obviously not async to prevent confusion): Observers carrying @Concurrent are running concurrently to each other (that’s the double-opt in case). Observers not having @Concurrent are handled like point 2. observer methods are not allowed to to have both, @Priority and @Concurrent 4. fire with @Observes and @Concurrent: Ability to use fire with some level of async. The behavior on the caller side does not change, fire waits until all observer method invocations are finished We should think also about ProcessObserverMethod. That’s the place where you can override any priority/(async|concurrent) settings and perhaps even the asyncSupported flag. This sort of opt-out is maybe sufficient. Now what happens, if asyncSupported=false and fireAsync? How about just skipping the observer? This feels like a dirty hack and in the end you can’t tell how your application will behave.