Details
-
Bug
-
Status: Closed
-
Major
-
Resolution: Won't Fix
-
1.1.0
-
None
-
None
-
Operating System: Windows XP
Platform: PC
-
36130
Description
I've experienced twice now where a page is submitted to an action, the action
forwwards to a forward whose path is another action with a dispatch parameter
(i.e. /client.do?dispatch=saveClient), and during this action, it returns
another forward to a dispatch action (/main.do?dispatch=afterClientWork).
During the execute method of the base DispatchAction, the call to get the
dispatch parameter, request.getParameter(...), returns the original dispatch
value ("saveClient"), not the most recent ("afterClientWork"). Upon examining
the query string, I find it to be
appended: "dispatch=saveClient&dispatch=afterClientWork".
I'm not certain what the Servlet spec means when its says that forward/include
should "merge" the query string of the requested URL into the request (for the
lifetime of the forward/include), but on WebSphere 5, it is appending it. And
when the DispatchAction calls getParameter, it is received the first parameter
value with that name, not the most recent.
In my particular use case, each of the actions in the chain could return
forwards to other pages, but in the best case scenario, furhter user ineraction
can be skipped, resulting in one action just forwarding to the next.
Also, I can't break this up with redirects because this will ultimately live in
a Portal, and portlets can't send redirects.
If parameter order can be guaranteed, then DispatchAction could be changed to
return the last "dispatch" parameter instead of the first. If not, then
perhaps RequestProcessor could be altered to recognized forwards to local, non-
redirect action mappings and invoke them programatically? This latter options
seems awful.