I think none of that is specified, therefore it's left to the implementations. So delivery in Weld - it depends on the executor used, i.e. if using daemon threads (all executors in Weld by default) an observer notification does not prevent the JVM from exiting. Note that even if an executor uses user threads the container itself may be already shut down before the notification finishes, i.e. contexts will be destroyed etc. Ordering of async observers in Weld - if serial notification mode is used (default, see also Chapter 11. Events ) Weld should honor the javax.annotation.Priority annotations used.

Thanks.  One last question.  To belabor the obvious, in serial mode, this is required to mean that all observers of a given event are notified on the same thread, right?  So observer 1's observer method will be called synchronously and will complete, and then observer 2's observer method will be called synchronously and will complete, and then observer 3's observer method will be called synchronously and will complete?  And all of this activity will take place on a single dedicated thread that is not the main container thread?

Exactly. The idea behind this concept is that it's a caller of Event.fireAsync() that benefits from asynchronicity and observers should not care about each other.

In English, "your first priority" is equal to "your highest priority", and "your second priority" is a lower priority than "your first priority".  I suspect that is not how javax.annotation.Priority works.  I assume that something annotated with @Priority(2) is to be preferred over something with @Priority(1)?

There was a discussion in CDI EG (see also [cdi-dev] [Vote] @Priority value order on ordered events ) and (unfortunately) my proposal did not pass. And so: "Observers with smaller priority values are called first." (see also JSR 365: Contexts and Dependency Injection for Java 2.0: ).