myfaces-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Martin Kočí (JIRA) <>
Subject [jira] [Commented] (MYFACES-3199) Handling AbortProcessingException is unconsistent
Date Mon, 04 Jul 2011 13:53:21 GMT


Martin Kočí commented on MYFACES-3199:

> 2a) exception is instance of APE _or any of the causes of the exception are an APE, don't_
> ExceptionQueuedEvent and terminate processing for current event _(is this as such in
the spec that an APE has to be queued?)_ 

Good question. 

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.

> Handling AbortProcessingException is unconsistent
> -------------------------------------------------
>                 Key: MYFACES-3199
>                 URL:
>             Project: MyFaces Core
>          Issue Type: Sub-task
>          Components: General
>         Environment: myface core trunk
>            Reporter: Martin Kočí
> UIViewRoot:
>  try  {
>     source.broadcast(event);
>  }
>             catch (AbortProcessingException e)
>             {
>                 ExceptionQueuedEventContext exceptionContext 
>                         = new ExceptionQueuedEventContext(context, e, source, context.getCurrentPhaseId());
>                 context.getApplication().publishEvent(context, ExceptionQueuedEvent.class,
>                 // Abortion
>                 return false;
> }
> Problem 1: 
> <h:inputText  valueChangeListener="#{bean.processValueChange}">
> MethodExpressionValueChangeListener wraps all exceptions to AbortProcessingException
and therefore exception is queued
> Problem 2: 
>             <h:inputText  >
>                 <f:valueChangeListener binding="#{bean}" />
>             </h:inputText>
> ValueChangeListenerHandler does not wrap exception to AbortProcessingException and therefore
 exception is not queued in this block (but it is queued from phase executor but without component
> Problem 3: JSF spec 2.1 : 
> "Clarification made: throwing an AbortProcessingException tells an implementation that
no further broadcast of the
> current event occurs. Does not affect future events." 
> But I think that code in UIViewRoot makes opposite:  // Abortion  return false;

This message is automatically generated by JIRA.
For more information on JIRA, see:


View raw message