http://djnweb2.sjc.collab.net/blog/209941
There is however another, more subtle, form of coupling taking place:  event dispatching usually happens in the same thread that fired the event. Event observers can perform some long-running tasks upon receiving an event, which will block this thread. This may or may not be a problem, depending on where the event proucer thread is located. If this thread is for instance a GUI event thread or a HTTP request processing thread then the end user may be forced to wait for a response from the application while a slow operation is taking place.

To solve this problem it would be nice to be able to process the events in a backhround thread. Unfortunately, the current CDI specification lacks such a feature.

There are many ways to work around this problem. The one I will present here involves creating a generic background event processing framework that can be used to process any application event in background using JMS as a dispatch mechanism. The Idea is to change the event processing wokflow from:

Event Producer -> Event Consumer(s) [foreground thread]

To:

Event Producer -> Event Sender -> JMS Queue [foreground thread]
JMS Queue -> Event Dispatcher -> Event Consumer [background thread]