爲什麼Event.fireAsync（）需要@ObservesAsync註解？

Question

在CDI 2.0中，一個can fire an event asynchronously通過調用Event.fireAsync()，然後通過@ObservesAsync帶註釋的偵聽器來收聽此事件。

爲什麼我們需要Event.firesAsync()和@ObservesAsync？

• 莫非不是CDI 2.0進程異步事件由Event.fire()解僱，與@ObservesAsync抓？
• 或者相反，爲什麼CDI 2.0不能異步處理由Event.fireAsync()和@Observes發起的事件？

Answer 1

確實是一個非常好的問題，這裏有一點洞察力。

CDI EG（專家組）決定對混合這兩種有以下幾個原因：

• 向後兼容性
  • 現有的應用程序使用同步，它需要表現同樣
  • 保持相同的註解會要求您添加額外的選項以區別
• 返回類型
  • 調用Event.fireAsync()給你一個CompletionStage您可以向其中鏈下一步驟，exceptionally()或thenApply()等這自然融入異步編程模型。
  • 好老Event.fire()只給你void，對此你不能反應在所有 - 不利於異步
  • 此外，同步型的返回值不能被改變，由於向後兼容
• 除外處理不同很多
  • 異常同步通知==鏈的端部，則炸燬在異步通知
  • 異常==你繼續前進，並從觀察者方法（可能來自多個線程！）收集所有異常，然後將它們呈現回調用代碼。由於它是CompletionStage，您可以輕鬆應對。
  • 將兩者混合會導致用戶方面產生一個非常令人困惑的結果 - 什麼時候你會炸燬，你什麼時候繼續？什麼是Event.fire()真正的結果（如果它是爲異步以及）
• 內部觀察者處理
  • 這將是非常複雜的（假設它甚至會是可能的）混合同步和異步
  • 請記住，您需要嚴格繪製一條線，在該線之間將同步和異步，因爲上下文不會在其他線程中傳播（例如RequestScoped需要在異步觀察器線程中由Weld重新激活）
  • 類似的麻煩來自安全上下文傳播f或集成
  • 往往存在預處理觀察員，使其工作非常快，如果你有兩個一個觀察者方法，你真的不能前處理它，你永遠不知道它會被用於
• 的fireAsync()存在允許您與其他選項
  火災事件：

  當前模型我能想到的其他優點0

• 有所謂NotificationOptions它允許你指定執行人您的通知
• 這也提供了更多的火力，以實現 - 焊接通過這些選項已經提供parallel execution and timeouts
• 最後但並非最不重要 - 用戶體驗
  • 這樣，它是明確的，那是你收到的工作方式完全相同
  • 並且對於fireAsync()你匹配@ObservesAsync