Hi 2011/7/11 Martin Koci <[email protected]>: > > Here is my opinion: > > the purpose of AbortProcessingException is similar as > ValidatorException or ConverterException. These are thrown as a result > of normal lifecycle processing. >
I agree with you. > > With AbortProcessingExpcetion it is (or should be) possible 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 throws > AbortProcessingExpcetion; but independent from the first one --> > </h:commandButton> > > That is a classic isolation of listeners in observer pattern. > Yes. > > Where is the problem? Specification works with APE inconsistently. First > it says that APE must be propagated to ExceptionHandler: "All other > Exception cases must not be swallowed, and must be allowed to flow up to > the Lifecycle.execute" (6.2 ExceptionHandler) but continues in "6.2.1 > Default ExceptionHandler implementation: Upon encountering the first > such Exception that is NOT an instance of > javax.faces.event.AbortProcessingException". So - APE is queued but > ignored in exception handler! Spec says that APE "the Exception must be > logged and not re-thrown." - but why propagate APE to exception handler > if the only result is log? > I think that behavior is correct, because you expect the ExceptionHandler deal with this kind of situation. Since it is an expected exception on the normal lifecycle, the only thing we can do by default is log the exception, but it should not cause an error page to be rendered. In this way, somebody can create a custom ExceptionHandler that detect this exception and deal with it gracefully. > Secondly, Application.publishEvent - "If the act of invoking the > processListener method causes an 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" - no words about exception handler. > Sounds bad idea just swallow the exception. Even if we are using the same event to deal with exceptions, something more consistent should be done in this part. > And third problem is described as MYFACES-3199. > Ok, here the spec has a lot of holes. > My proposition is to work with APE as follows (if TCK allows it): > > 1) AbortProcessingException is 'expected' exception and users can throw > it from listener in same manner as they can throw ConverterExpcetion > from converters and ValidatorException from validators > Agreed > 2) Isolate listeners and work with APE with algorithm suggested in > MYFACES-3199 > Could you be more specific in this part? just to be clear how finally will looks like. > 3) Unify working with APE in myfaces code: we can introduce new param > "rethrowEveryListenerExceptionAsAPE" to preserve current behaviour. > Sounds good, but we have to face the fact that in anyway the spec is poor in this area and follow it leads to inconsistencies. In other words, since the spec has inconsistencies we should define a clear behavior and submit it to the EG. Use a param to keep compatibility with a inconsistent behavior seems bizzare in any case. This issue reminds me the problem with MYFACES-3157 Fix order of isRendered and pushComponentToEL invocations. The spec is clear about what to do, but in practice that behavior is inconsistent and must be changed, even if with this change deliberately MyFaces Core will behave different than the reference implementation (Mojarra). We don't have choice if we want to preserve a coherent behavior in our JSF impl. regards, Leonardo Uribe > > Martin Koci píše v Čt 07. 07. 2011 v 14:10 +0200: >> Hi, >> >> >> what is purpose of AbortProcessingException in JSF API? >> >> Please see https://issues.apache.org/jira/browse/MYFACES-3199 > >> Currently specification and myfaces work with it unconsistently. >> >> Do you have example of usage in your JSF applications? >> >> >> Regards, >> >> Kočičák >> >> >> >> > > >
