[ http://issues.apache.org/jira/browse/JS2-9?page=history ]
Ate Douma closed JS2-9:
-----------------------
Resolution: Fixed
Fix Version: 2.0-dev/cvs
2.0-M2
2.0-FINAL
Finally, closure to this problem.
While I was reinvestigating this problem because I had to document the
workaround I implemented for the
Struts Bridge I determined a way to solve it generally for the Portal.
Side effect of this is that I now can remove the workaround from the Struts
Bridge again (which is nice).
I fixed this by flushing the parameterMap when the wrapped request object was
changed as Tomcat does
when it reuses the HttpServletRequestWrapper for an RequestDispatcher.include.
> Caching of portal parameters
> o.a.j.engine.servlet.ServletRequestImpl.getParameterMap() prevents subsequent
> RequestDispatcher invokation query string parameter merging
> ----------------------------------------------------------------------------------------------------------------------------------------------------------------------
>
> Key: JS2-9
> URL: http://issues.apache.org/jira/browse/JS2-9
> Project: Jetspeed 2
> Type: Bug
> Versions: 2.0-dev/cvs
> Environment: Windows XP, J2SE1.4.2_03, Tomcat 4.1.29
> Reporter: Ate Douma
> Assignee: Ate Douma
> Priority: Blocker
> Fix For: 2.0-dev/cvs, 2.0-M2, 2.0-FINAL
>
> Sorry for the long summary but I couldn't think of something shorter.
> The o.a.j.engine.servlet.ServletRequestImpl.getParameterMap() only retrieves
> the portal parameters on first access and stores them in a Map which is
> returned on subsequent requests.
> This seems smart from performance but actually is killing when a portlet
> wants to include a servlet or jsp with a RequestDispatcher and needs to
> specify additional query parameters (on the path).
> On invokation of the RequestDispatcher Tomcat (at least) unwraps the
> ServletRequest chain of ServerRequestWrappers until it finds one of its own
> or one which is not an instance of ServletRequestWrapper (in
> org.apache.catalina.core.ApplicationDispatcher.wrapRequest()). Then it plugs
> a new HttpServletRequestWrapper into that part of the chain so it can merge
> any query string parameters on *top* of whatever parameters were already
> defined.
> This all means that the set of request parameters will have been changed
> BELOW the o.a.j.engine.servlet.ServletRequestImpl (funny method name:
> wrapRequest() if you think of it ;-)
> Because of the parameter caching these will however NOT become available to
> the included servlet or jsp.
> Personnally I don't understand why Tomcat is not wrapping the request instead
> of plugging itself lower into the chain. Probably this should be reported as
> a bug to Tomcat.
> But for the moment the current problem should be fixed I think by no longer
> caching the parameters in o.a.j.engine.servlet.ServletRequestImpl because its
> blocking my StrutsPortlet framework because its a common practice in struts
> applications to use query string parameters on actionforwards.
> Ate
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
If you want more information on JIRA, or have a bug to report see:
http://www.atlassian.com/software/jira
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
