[ http://issues.apache.org/struts/browse/SHALE-336?page=comments#action_38770 ] Gary VanMatre commented on SHALE-336: -------------------------------------
>I'm wondering if this might even make the catching in ViewActionListener >redundant? I think that it would be redundant. The apply request values phase ends up calling decode on the command components. They queue up an ActionEvent if the command was invoked. The event is targeted for the apply request values or invoke application phase depending on the immediate flag. The event is propagated all the way up to the view root. At the end of the apply request values or a couple phase later in the invoke application phase, the view root finds the action event and invokes the broadcast on the command . In the command's broadcast method the listeners are invoked first and then the global ActionListener. So, the listeners and action are invoked from the processApplication or processDecodes methods of the view root. I had forgot about the immediate options. >We should also look at extending this idea to deal with value change listener >events too, if it can be done in a similar fashion. I think we could but we would have to hook into the processDecodes() and processValidators() methods of the view root since these guys would be queue early if the immediate flag was turned on. That only leaves the processUpdates(). I think we could capture exceptions here too because the response is completed when a runtime exception is raised. Should be try wrappering processDecodes, processValidators, processUpdates and processApplication? > Exceptions raised in action listeners are exempt from the exception handing > strategy of the view controller. > ------------------------------------------------------------------------------------------------------------ > > Key: SHALE-336 > URL: http://issues.apache.org/struts/browse/SHALE-336 > Project: Shale > Issue Type: Improvement > Components: View > Affects Versions: 1.0.4-SNAPSHOT > Reporter: Gary VanMatre > Priority: Minor > Attachments: view.patch > > > The action listener events are fire by the lifecycle in the invoke > application phase. If an exception is raised, there is not a trap similar to > the ViewActionListener for handling action event invocation exceptions. > In an attempt to make the error handing strategy consistent between the two > types of application callbacks, I propose that we subclass the view root and > override the processApplication method. Within this overridden method, we > trap the exceptions and add them to the exceptions list. > I'm not sure what side effects this might have but I thought it should be > discussed first. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/struts/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
