You are viewing a plain text version of this content. The canonical link for it is here.
Posted to jetspeed-dev@portals.apache.org by ji...@apache.org on 2004/04/09 03:49:43 UTC
[jira] Created: (JS2-9) Caching of portal parameters o.a.j.engine.servlet.ServletRequestImpl.getParameterMap() prevents subsequent RequestDispatcher invokation query string parameter merging
Message:
A new issue has been created in JIRA.
---------------------------------------------------------------------
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: Thu, 8 Apr 2004 6:48 PM
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: jetspeed-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: jetspeed-dev-help@jakarta.apache.org
[jira] Assigned: (JS2-9) Caching of portal parameters o.a.j.engine.servlet.ServletRequestImpl.getParameterMap() prevents subsequent RequestDispatcher invokation query string parameter merging
Posted by "Ate Douma (JIRA)" <je...@jakarta.apache.org>.
[ http://issues.apache.org/jira/browse/JS2-9?page=history ]
Ate Douma reassigned JS2-9:
---------------------------
Assign To: Ate Douma (was: David Sean Taylor)
> 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: jetspeed-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: jetspeed-dev-help@jakarta.apache.org
[jira] Closed: (JS2-9) Caching of portal parameters o.a.j.engine.servlet.ServletRequestImpl.getParameterMap() prevents subsequent RequestDispatcher invokation query string parameter merging
Posted by "Ate Douma (JIRA)" <je...@jakarta.apache.org>.
[ 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: jetspeed-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: jetspeed-dev-help@jakarta.apache.org
[jira] Commented: (JS2-9) Caching of portal parameters o.a.j.engine.servlet.ServletRequestImpl.getParameterMap() prevents subsequent RequestDispatcher invokation query string parameter merging
Posted by ji...@apache.org.
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: jetspeed-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: jetspeed-dev-help@jakarta.apache.org
[jira] Commented: (JS2-9) Caching of portal parameters o.a.j.engine.servlet.ServletRequestImpl.getParameterMap() prevents subsequent RequestDispatcher invokation query string parameter merging
Posted by ji...@apache.org.
The following comment has been added to this issue:
Author: Ate Douma
Created: Fri, 9 Apr 2004 2:41 AM
Body:
This one is even trickier than I thought.
I traced back the org.apache.catalina.core.ApplicationDispatcher.wrapRequest() implementation causing all this to 2001-07-16 and based on Bugzilla bug #1902.
It turns out that this not wrapping of the passed on request but instead pluggin in somewhat below it in the chain is required per the Servlet 2.3 spec SRV.6.2.2 Wrapping Requests and Responses (for Filtering): The passed on request and response objects MUST be the same objects which were used to invoke!
But that means that even if parameter caching is turned off in o.a.j.engine.servlet.ServletRequestImpl it still won't be possible to dynamicaly inject additional parameters in a request (which is about the only purpose of the o.a.j.engine.servlet.ServletRequestImpl and needed to comply to the portlet specs) without the possibility of violating the specs for Servlet RequestDispatcher / Portlet PortletDispatcher handling of query string parameters.
According to those specs query parameters defined on the dispatcher path must take precedence over already defined parameters in the request used for invokation for the duration of the invokation.
This means that if the request has parameter X=2 and the query string defins X=3 the called servlet must see as values for parameter X: [3,2](3 taking precendence over 2).
But, because of the SRV.6.2.2 requirement Tomcat is forced to use the solution that have taken by injecting the parameters in a lower part of the request handler chain.
Thus if parameter X=2 is injected as portal parameter by o.a.j.engine.servlet.ServletRequestImpl it has to give it precendence over any already defined parameter in the request. Thus in this case if parameter X=3 was defined on the query string of an included servlet from the portlet it will see as values for parameter X: [2,3] which is a violation of the portlet spec PLT.16.1.1.
The only way out of this seems to me to handle query parameters on
request dispatcher paths within the portlet container and NOT rely on the servlet container as that clearly won't work.
So, when a PortletRequestDispatcher is invoked with query parameters on the path it should wrap the request and parse the query parameters itself and inject them in aditional overriden parameter getters.
This will NOT be in violation of SRV.6.2.2 because that only is defined for filtering which is not the case here.
For my Struts Portlet framework in which I already trap any RequestDispatcher invokations I will implement this myself. This isssue, although serious and should be handled, thus won't be blocking anymore rightnow.
I will try to create an generic solution so that if needed it can also be used by Jetspeed.
I just hope I'm not interpreting this all completely wrong and end up making a lot of changes for nothing ;-).
Anyway, as I read the specs now there seems to be a clear conflict between the requirements of SRV.6.2.2, SRV.8.1.1 (which is where PLT.16.1.1. is based upon) and the whole purpose of the ServletRequestWrapper which is meant to be used to extend/override behavior like parameter handling.
Ate
---------------------------------------------------------------------
View this comment:
http://issues.apache.org/jira/browse/JS2-9?page=comments#action_28057
---------------------------------------------------------------------
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:41 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: jetspeed-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: jetspeed-dev-help@jakarta.apache.org
[jira] Assigned: (JS2-9) Caching of portal parameters o.a.j.engine.servlet.ServletRequestImpl.getParameterMap() prevents subsequent RequestDispatcher invokation query string parameter merging
Posted by ji...@apache.org.
Message:
The following issue has been re-assigned.
Assignee: David Sean Taylor (mailto:taylor@apache.org)
---------------------------------------------------------------------
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: Open
Priority: Blocker
Project: Jetspeed 2
Versions:
2.0-dev/cvs
Assignee: David Sean Taylor
Reporter: Ate Douma
Created: Thu, 8 Apr 2004 6:48 PM
Updated: Wed, 5 May 2004 2:25 PM
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: jetspeed-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: jetspeed-dev-help@jakarta.apache.org