portals-jetspeed-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From j...@apache.org
Subject [jira] Assigned: (JS2-9) Caching of portal parameters o.a.j.engine.servlet.ServletRequestImpl.getParameterMap() prevents subsequent RequestDispatcher invokation query string parameter merging
Date Wed, 05 May 2004 21:26:56 GMT
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


Mime
View raw message