> 2a) exception is instance of APE or any of the causes of the exception are an APE, don't publish
> ExceptionQueuedEvent and terminate processing for current event (is this as such in the spec that an APE has to be queued?)
A) from specification document "6.2.1 Default ExceptionHandler implementation" - " ... upon encountering the first such Exception that is not an instance of javax.faces.event.AbortProcessingException ... "
B) from JavaDoc Application.publishEvent : "... invoking the processListener method causes an javax.faces.event.AbortProcessingException to be thrown, processing of the listeners must be aborted, no further processing of the listeners for this event must take place, and the exception must be logged with Level.SEVERE"
And that's all - specification is pretty poor in this area.
ad A) this part expects AbortProcessingException to be queued for exception handler: but it does not make sense: AbortProcessingException is exception for controlling code flow and user can use it in same way as ValidatorException and ConverterException - those exceptions are not published.
ad B) "exception must be logged with Level.SEVERE" no mention of publish but still weird: again, I think AbortProcessingException is expected exception - why logging it as severe ( funny: specification speaks about java.util.logging API directly)
So, I completely agree with improved 2a) "exception is instance of APE or any of the causes of the exception are an APE, DON'T publish ExceptionQueuedEvent and terminate processing for current event".
We should do a logging improvement here; if APE terminates processing for current event, output a log "Processing of .. was terminated with APE ..." but surely log level according to project stage (not severe) - I'll create separate subtask of MYFACES-3053 for it.