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
Description
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
Bug
Closed
Blocker
Caching of portal parameters o.a.j.engine.servlet.ServletRequestImpl.getParameterMap() prevents subsequent RequestDispatcher invokation query string parameter merging
