shale-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Gary VanMatre (JIRA)" <j...@apache.org>
Subject [jira] Commented: (SHALE-336) Exceptions raised in action listeners are exempt from the exception handing strategy of the view controller.
Date Fri, 17 Nov 2006 20:33:57 GMT
    [ 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

        

Mime
View raw message