The following comment has been added to this issue:
Author: Ate Douma
Created: Fri, 9 Apr 2004 2:54 AM
Body:
One little addition.
In the portlet spec there is no mention of a restriction like SRV.6.2.2. It seems that
for the current spec it is allowed for the portlet container to pass on wrapped
request objects to a included servlet. But, once filtering is going to be supported in
a future version of the spec it wouldn't supprise me to see this requirement also to
be applied.
So, maybe this issue should be passed on to the spec leaders to look into? (I have no
idea who's on that)
---------------------------------------------------------------------
View this comment:
http://issues.apache.org/jira/browse/JS2-9?page=comments#action_28058
---------------------------------------------------------------------
View the issue:
http://issues.apache.org/jira/browse/JS2-9
Here is an overview of the issue:
---------------------------------------------------------------------
Key: JS2-9
Summary: Caching of portal parameters
o.a.j.engine.servlet.ServletRequestImpl.getParameterMap() prevents subsequent
RequestDispatcher invokation query string parameter merging
Type: Bug
Status: Unassigned
Priority: Blocker
Project: Jetspeed 2
Versions:
2.0-dev/cvs
Assignee:
Reporter: Ate Douma
Created: Thu, 8 Apr 2004 6:48 PM
Updated: Fri, 9 Apr 2004 2:54 AM
Environment: Windows XP, J2SE1.4.2_03, Tomcat 4.1.29
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
---------------------------------------------------------------------
JIRA INFORMATION:
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]
