[
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
