[
https://issues.apache.org/jira/browse/MYFACES-3199?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13059436#comment-13059436
]
Martin Kočí commented on MYFACES-3199:
--------------------------------------
> 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?)_
Good question.
A) from specification document "6.2.1 Default ExceptionHandler implementation"
- " ... upon encountering the first such Exception that is not an instance of
javax.faces.event.AbortProcessingException ... "
B) from JavaDoc Application.publishEvent : "... invoking the processListener
method causes an javax.faces.event.AbortProcessingException to be thrown,
processing of the listeners must be aborted, no further processing of the
listeners for this event must take place, and the exception must be logged with
Level.SEVERE"
And that's all - specification is pretty poor in this area.
ad A) this part expects AbortProcessingException to be queued for exception
handler: but it does not make sense: AbortProcessingException is exception for
controlling code flow and user can use it in same way as ValidatorException and
ConverterException - those exceptions are not published.
ad B) "exception must be logged with Level.SEVERE" no mention of publish but
still weird: again, I think AbortProcessingException is expected exception -
why logging it as severe ( funny: specification speaks about java.util.logging
API directly)
So, I completely agree with improved 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".
We should do a logging improvement here; if APE terminates processing for
current event, output a log "Processing of .. was terminated with APE ..." but
surely log level according to project stage (not severe) - I'll create
separate subtask of MYFACES-3053 for it.
> 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
