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/05/05 23:26:56 UTC

[jira] Assigned: (JS2-9) Caching of portal parameters o.a.j.engine.servlet.ServletRequestImpl.getParameterMap() prevents subsequent RequestDispatcher invokation query string parameter merging

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