[
https://issues.apache.org/jira/browse/MYFACES-3199?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13058467#comment-13058467
]
Martin Kočí commented on MYFACES-3199:
--------------------------------------
What is exactly the purpose of AbortProcessingException compared to normal
RuntimeException?
>From JavaDoc: AbortProcessingException "An exception that may be thrown by
>event listeners to terminate the processing of the current event."
JSF 2.1 spec contains also clarification:
3.4.2.6 Event Broadcasting - listener processing an event may ... Throw an
AbortProcessingException, to tell the JSF implementation that no further
broadcast of this event should take place."
and "Clarification made: throwing an AbortProcessingException tells an
implementation that no further broadcast of the
current event occurs. Does not affect future events."
My initial thought was use this in following case:
<h:commandButton>
<f:actionListener ...>
<f:actionListener ...> <!-- This one throws AbortProcessingExpcetion -->
<f:actionListener ...>
</h:commandButton>
Author of view knows that third one listener cannot work if second one fail and
therefore throws AbortProcessingException explicitly.
But this behaviour is same for unexpected exception form listener - it
terminates execution of listeners. The only difference is that default
ExceptionHandler ignores AbortProcessingException in stack
Wasn't the original purpose of AbortProcessingException and ExceptionHandler to
achieve this:
<h:commandButton>
<f:actionListener ...> <!-- may throw a exception - if it does it will be
queued for exception handling; but broadcasting continues -->
<f:actionListener ...> <!-- This one throws AbortProcessingExpcetion -->
<f:actionListener ...> <!-- not executed if previous AbortProcessingExpcetion;
but independent from first one -->
</h:commandButton>
That is a classic isolation of listeners in observer pattern.
> 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
