[ 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