myfaces-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Leonardo Uribe (JIRA)" <...@myfaces.apache.org>
Subject [jira] Resolved: (MYFACES-2216) MyFaces suppresses runtime exceptions thrown in ActionListeners
Date Mon, 26 Oct 2009 18:26:59 GMT

     [ https://issues.apache.org/jira/browse/MYFACES-2216?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]

Leonardo Uribe resolved MYFACES-2216.
-------------------------------------

       Resolution: Fixed
    Fix Version/s: 1.2.8-SNAPSHOT

> MyFaces suppresses runtime exceptions thrown in ActionListeners
> ---------------------------------------------------------------
>
>                 Key: MYFACES-2216
>                 URL: https://issues.apache.org/jira/browse/MYFACES-2216
>             Project: MyFaces Core
>          Issue Type: Bug
>          Components: JSR-252
>    Affects Versions: 1.2.6, 1.2.7-SNAPSHOT
>         Environment: Tomcat 6.0.18, JRE 1.6.11
>            Reporter: Dirk Möbius
>            Assignee: Leonardo Uribe
>             Fix For: 1.2.8-SNAPSHOT
>
>
> Have a look at the following stack trace when a custom ActionListener throws an unhandled
exception:
> com.myproject.validation.ValidationException
>  	at com.myproject.controller.MyController.validate(MyController.java:50)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> 	at java.lang.reflect.Method.invoke(Method.java:597)
> 	at org.apache.el.parser.AstValue.invoke(AstValue.java:172)
> 	at org.apache.el.MethodExpressionImpl.invoke(MethodExpressionImpl.java:276)
> 	at org.apache.jasper.el.JspMethodExpression.invoke(JspMethodExpression.java:68)
> 	at javax.faces.event.MethodExpressionActionListener.processAction(MethodExpressionActionListener.java:49)
> 	at javax.faces.event.ActionEvent.processListener(ActionEvent.java:51)
> 	at javax.faces.component.UIComponentBase.broadcast(UIComponentBase.java:554)
> 	at javax.faces.component.UICommand.broadcast(UICommand.java:124)
> 	at javax.faces.component.UIViewRoot._broadcastForPhase(UIViewRoot.java:369)
> 	at javax.faces.component.UIViewRoot.process(UIViewRoot.java:264)
> 	at javax.faces.component.UIViewRoot.processApplication(UIViewRoot.java:153)
> 	at org.apache.myfaces.lifecycle.InvokeApplicationExecutor.execute(InvokeApplicationExecutor.java:32)
> 	at org.apache.myfaces.lifecycle.LifecycleImpl.executePhase(LifecycleImpl.java:103)
> 	at org.apache.myfaces.lifecycle.LifecycleImpl.execute(LifecycleImpl.java:76)
> 	at org.apache.myfaces.custom.ppr.PPRLifecycleWrapper.execute(PPRLifecycleWrapper.java:68)
> 	at javax.faces.webapp.FacesServlet.service(FacesServlet.java:151)
> In MethodExpressionActionListener.processAction(ActionEvent), any exception is wrapped
into an AbortProcessingException:
>     public void processAction(ActionEvent actionEvent) throws AbortProcessingException
{
>         try {
>             Object[] params = new Object[]{actionEvent};
>             methodExpression.invoke(elContext(), params);
>         } catch (Exception e) {
>             throw new AbortProcessingException(e);
>         }
>     }
> Deeper down in the stack trace, any AbortProcessingException is silently ignored in method
UIViewRoot.__broadcastForPhase(PhaseId phaseId) : 
>     private void _broadcastForPhase(PhaseId phaseId) {
>         ...
>                 try
>                 {
>                     source.broadcast(event);
>                 }
>                 catch (AbortProcessingException e)
>                 {
>                     // abort event processing
>                     // Page 3-30 of JSF 1.1 spec: "Throw an
>                     // AbortProcessingException, to tell the JSF implementation
>                     // that no further broadcast of this event, or any further
>                     // events, should take place."
>                     abort = true;
>                     break;
>                 }
>         ...
>     }
> Mojarra logs the exception at least (twice, in fact). But IMHO unhandled exceptions should
make it to the top-level to be handled by custom error handlers or phase listeners. The spec
is not explicit about unhandled exceptions in ActionListeners. Sec 3.4.7 ("Event broadcasting")
simply states:
> During event broadcasting, a listener processing an event may:
> * Examine or modify the state of any component in the component tree.
> * Add or remove components from the component tree.
> * Add messages to be returned to the user, by calling addMessage on the
> FacesContext instance for the current request.
> * Queue one or more additional events, from the same source component or a different
one,
> for processing during the current lifecycle phase.
> * Throw an AbortProcessingException, to tell the JSF implementation that no
> further broadcast of this event, or any further events, should take place.
> * Call renderResponse() on the FacesContext instance for the current request.[...]
> * Call responseComplete() on the FacesContext instance for the current request.[...]
> The best solution, IMHO, would be that MyFaces stores the unhandled exception in its
internal queued exception list (request param "org.apache.myfaces.errorHandling.exceptionList")
so that it won't get lost and can be inspected by custom code later.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


Mime
View raw message