[jira] Resolved: (PLUTO-530) RequestDispatcher path query string parameter handling too limited and broken with nested dispatches

["Ate Douma (JIRA)" <ji...@apache.org>]

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

Ate Douma resolved PLUTO-530.
-----------------------------

    Resolution: Fixed

All fixed and implemented with the recent big bang refactoring and final commits r753592 and r753593

> RequestDispatcher path query string parameter handling too limited and broken with nested dispatches
> ----------------------------------------------------------------------------------------------------
>
>                 Key: PLUTO-530
>                 URL: https://issues.apache.org/jira/browse/PLUTO-530
>             Project: Pluto
>          Issue Type: Bug
>          Components: portlet container
>    Affects Versions: 2.0.0
>            Reporter: Ate Douma
>            Assignee: Ate Douma
>            Priority: Critical
>             Fix For: 2.0.0
>
>
> Below copied (in part) from email discussion on the Pluto dev list, see also: http://www.nabble.com/More-required-Pluto-2.0-SPI-and-implementation-refactoring-issues-td21973310.html
> *** RequestDispatcher path query string parameter handling
> PLT.19.4.1 specifies that "The request dispatching mechanism is responsible for aggregating query string parameters when forwarding or
> including requests".
> This requirement has been implemented very literally in Pluto: a PortletRequestDispatcher path query string is "stored" in the request instance and on subsequent access to the parameter map from within the invoked servlet parsed and merged on top of the portlet parametermap.
> This "manual" processing and merging of query string parameters however breaks the Servlet spec requirements!
> It goes wrong if from within the dispatched servlet a subsequent dispatch is performed with additional query string parameters.
> In the current solution, this possible usage hasn't been taken into account, with as result you'll *always* receive the same
> parametermap on subsequent (nested) dispatches (for example from within a JSP including another JSP).
> But, even if the servletrequest.getRequestDispatcher(path) would be overridden to "fix" this problem, that still won't solve it for two reasons:
> - ServletContext.getRequestDispatcher(path) *cannot* be overridden, therefore still leaving a "hole" in the solution
> - there is no "returned from dispatch" callback mechanism to "revert" the current parametermap after a dispatch
> Therefore, "manual" parsing and merging of dispatcher query string parameters *cannot* be used to implement this spec requirement.
> However, the correct way to implement this is actually extremely simple: just let the servlet container handle it all by itself!
> There is no need to "store", parse and merge dispatcher query string parameters, and in the servletrequest(wrapper).getParameterMap(), just return super.getParameterMap() which the container will have "injected" with the additional query string parameters merged already.
> Jetspeed-2 has used this solution from the beginning (with some additional fancy cache handling) and it just works as expected.
> Changing to this solution will dramatically simplify the current implementation, especially after the PortletRequest and ServletRequest
> implementations are split up (see: PLUTO-529).
> (side note: I actually wrote a testcase for this and this spec requirement is broken in most other open-source portlet containers as well!)

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