[ http://mc4j.org/jira/browse/STS-378?page=all ]
Ben Gunter resolved STS-378.
----------------------------
Resolution: Fixed
This has been resolved in that when ForwardResolution(Class<? extends
ActionBean>, String) is called the specified event will always be preferred
over whatever may be indicated by the request parameters. There is still some
ill-defined behavior when calling ForwardResolution(String) and
ForwardResolution(Class<? extends ActionBean>) though. The event is not
specified when calling these constructors, but none of Stripes' documentation
is clear on whether this method is intended to always call the default handler
or whether it is supposed to use the normal algorithm to determine what handler
to call. Since an argument could be made for either approach, I will leave it
alone for now.
> incorrect event handler invoked with ForwardResolution(Class<? extends
> ActionBean>, String)
> -------------------------------------------------------------------------------------------
>
> Key: STS-378
> URL: http://mc4j.org/jira/browse/STS-378
> Project: Stripes
> Issue Type: Bug
> Components: ActionBean Dispatching
> Affects Versions: Release 1.4.3
> Reporter: Ben Gunter
> Assigned To: Ben Gunter
> Fix For: Release 1.5
>
> Attachments: TestAction.java
>
>
> When a request is received with an explicit event name, like so
> /my/action?foo=
> and that request is forwarded to another (or the same) ActionBean that has an
> event with the same name but a different event is intended to fire, like so
> return new ForwardResolution(getClass(), "bar")
> the original event often will fire on the forwarded request instead of the
> intended event because the original event name is still present as a request
> parameter. This leads to stack overflow or other such problems.
> The event that fires on the forwarded request is determined by the order in
> which the event handler methods are stored in the event handler cache in
> AnnotatedClassActionResolver. The first one whose name is found as a request
> parameter is determined to be the intended event.
> One possible solution to this problem is for ForwardResolution(Class<?
> extends ActionBean>, String) to add the event name as both a request
> parameter and as a request attribute.
> AnnotatedClassActionResolver.getEventName() would check for event as a
> request attribute first and then examine the request parameters after that.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://mc4j.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
-------------------------------------------------------------------------
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
_______________________________________________
Stripes-development mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/stripes-development
