Details
-
Bug
-
Status: Closed
-
Major
-
Resolution: Fixed
-
1.2.12-core
-
None
-
This is a generic issue, not specific to any OS/HD etc.
Description
We have a use-case where nested EL is involved. For example, a button which is associated with an EL:
#
{component.processButton}"When this EL is invoked, it will execute the following EL:
#{bindings.Commit.execute}
Suppose there is an expected error when the command is executed (txn error, etc), we would have the following to wrapp/unwrapp the base exception all the way back:
First for #{bindings.Commit.execute}:
->ADFm-layer (e.g. EOImpl) throws JBOException e1
->FacesCtrlActionBinding.execute(ActionEvent ae) catches e1 and throws AbortProcessingException e2
->e2 was wrapped into InvocationTargetException e3 (e3's cause is e2) by sun.reflect.NativeMethodAccessorImpl.invoke()
->com.sun.el.parser.AstValue.invoke() catches e3 and rewrap the exception to ELException e4 (e4's cause is e2)
Now flow is back to #{component.processButton}
:
->because of an exception e4 from #
, e4 is wrapped into InvocationTargetException e5 (e5's basue is e4)
->com.sun.el.parser.AstValue.invoke() catches e5 and rewrap the exception to ELException e6 (e6's cause is e4)
So we have e6(of type ELException) whose cause is e4(of type ELException) whose cause is e2 (of type AbortProcessingException)
->trinidad MethodExpressionMethodBinding will catch e6 and rewrap it into EvaluationException e7 (i.e. e7's cause is e4, e4's cause is e2)
->trinidad UIXcomponentBase catches e7 and tries to check whether the base exception is AbortProcessingException or not, if true, a log message will just be logged and the lifecycle continues. But since we have nested EL, so when e7 is unwrapped, we still have ELException e4, causing the whole lifecycle aborted.
I think that UIXComponentBase's code looking for AbortProcessingExceptions should look like this
Throwable currThrowable = exception;
while (currThrowable)
{
if (currThrowable instanceof AbortProcessingException)
currThrowable = currThrowable.getCause();
}