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.
