Hi.
Wouldn't a third risk (show stopper) be that the phaselistener registered in the thread for one request would be notified of phase events for other simultaneously serviced requests ?
Phase events have request/session/application scope as well as backing beans, so no risk there. Backing beans are saved as attributes of the request/session/application context, so what is needed is simply a dispatching phase listener, which gets the faces context, goes through the attributes of the request/session/appcontext, tests if a given attribute value implements the PhaseListener interface, checks if this phase listener is interested in the given phase and invokes the "before" or "after" methods appropriately. I've posted an example of dispatching phase listener for sessions earlier.
Bye. /lexi
