myfaces-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Leonardo Uribe (Commented) (JIRA)" <>
Subject [jira] [Commented] (MYFACES-3199) Handling AbortProcessingException is unconsistent
Date Fri, 09 Mar 2012 17:36:58 GMT


Leonardo Uribe commented on MYFACES-3199:

Ok, now I get it. 

MK>> Problem1 : UIViewRoot._broadcastAll queues APE into ExceptionQueuedEvent and 
MK>> check for "any of the causes of the exception are an APE" is missing in code

The check is done in the wrappers. See javax.faces.event.MethodExpressionActionListener, javax.faces.event.MethodExpressionValueChangeListener.
I think an additional check on UIViewRoot is not necessary.

MK>> ad Problem 2) queuing the source component is required to solve the mail goal 
MK>> of MYFACES-3053: "any time there is an error in *any* part of the 
MK>> lifecycle, the user should see not just a cryptic stack trace, but also the
MK>>  **component** - including file and line number - that triggered the problem" 

The patch has some side effects. UIViewRoot._process(FacesContext context, PhaseId phaseId,
PhaseProcessor processor) as a try {} catch block for RuntimeExceptions, to execute afterPhase
listeners and then rethrow the exception. Later, on LifecycleImpl the exception is catched
and finally published as an EventQueuedException.

In few words, the change proposed here is just publish EventQueuedException for non APE exceptions
in UIViewRoot._broadcastAll too, but preserve the effect of stop broadcasting when a non APE
exception is received. 

If you provide a patch removing the check for nested APE, and if no objections I'll review
it and commit 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čí
>            Assignee: Leonardo Uribe
>             Fix For: 2.0.9, 2.1.3
>         Attachments: UIViewRoot.patch
> 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.
If you think it was sent incorrectly, please contact your JIRA administrators:!default.jspa
For more information on JIRA, see:


View raw message