myfaces-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Leonardo Uribe (JIRA)" <...@myfaces.apache.org>
Subject [jira] [Commented] (MYFACES-3199) Handling AbortProcessingException is unconsistent
Date Mon, 12 Sep 2011 16:16:09 GMT

    [ https://issues.apache.org/jira/browse/MYFACES-3199?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13102765#comment-13102765
] 

Leonardo Uribe commented on MYFACES-3199:
-----------------------------------------

With the analysis done on MYFACES-3301, it becomes clear how to solve this problem. 

The first part we need to do is make clear the "context" behind the sentence:

"... If that fails for any reason, throw an AbortProcessingException, including the cause
of the failure. ..." 

After thinking a lot about it, we should not interpret it literally. Instead, the conclusion
is the part is an advice for the developer implementing a listener in the method expressions
that could be wrapped by this class. In other words, it is responsibility of the developer
to throw AbortProcessingException if it "fails for any reason". That has a lot more sense
than throw an APE for each exception without questions.

With the previous problem understood, how can we solve the inconsistent behavior for problem
1 and 2? Just do what was already agreed but with a change:

1) execute one listener in try catch block and catch (Exception e)
2) if
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?)_
2b) for any other exception publish ExceptionQueuedEvent [REMOVE THE FOLLOWING FRAGMENT ---
and continue broadcast processing ---]
3) handle queued exception in exception handler
3a) default exception handler : ignore AbortProcessingException
3b) custom exception handler: can handle all unexpected exception (for example remove them
from queue)
4) all unhandled exception are rethrow and error page is displayed 

We can't continue broadcast processing if other exception is thrown, because that requires
a change in the spec, so we are stuck in this part. 

Anyway, the previous algorithm is consistent, it has sense and comply with the spec. 



> Handling AbortProcessingException is unconsistent
> -------------------------------------------------
>
>                 Key: MYFACES-3199
>                 URL: https://issues.apache.org/jira/browse/MYFACES-3199
>             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,
exceptionContext);
>                 
>                 // 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
info)
> 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: http://www.atlassian.com/software/jira

       

Mime
View raw message