Hi Ate, OK, I made the changes you detailed and tried this and what happens is:
(1) Clicking on link goes to LocaleAction (ActionUrl). Using remote debugging in eclipse with a breakpoint in LocaleAction.execute(), the PortletServletRequestWrapper object contains an ApplicationContextFacade and a ServletRequestImpl. The ServletRequestImpl contains an ApplicationHttpRequestObject. The queryParamString member of the ApplicationHttpRequestObject holds the params "language=ja&forward=testredirect". (This is what I saw in my example also) (2) In LocaleAction the following code is run: target = request.getParameter(FORWARD); This returns null - the parameter "forward=testredirect" is not found in the request. This causes the following code to be executed: if (isBlank(target)) target = mapping.getParameter(); .... return mapping.findForward(target); "target" is the default welcome global mapping from the struts-config.xml, so the WelcomeAction is called. So in fact for me it appears that request params are being lost wholesale - irrespective of whether or not it is a redirect or a simple forward. I am using Tomcat 5.5.4, Windows XP, JDK 1.4.2_05, JetSpeed M1. I will try later today with Tomcat 5.0.28 which I also have. If I run the above code with the old version - which expressly parses the querystring in StrutsPortlet and passes it into PortletServletRequestWrapper, it works as you describe. I'm a bit stumped here. :-) Can you help me understand where the params go in the new PortletServletRequestWrapper? In the old PortletServletRequestWrapper I could see that in DispatchedHttpServletRequestWrapper they were parsed into a map. I'm unsure as to where they end up now. Thanks, Colin. -----Original Message----- From: Ate Douma [mailto:[EMAIL PROTECTED] Sent: 09 March 2005 22:41 To: Jetspeed Users List Subject: Re: Struts bridge, lost request parameters Colin, I took some time to create a testcase with a similar flow as you described earlier. For this, I used the struts-demo as provided with Jetspeed-2. Could you please check if this is indeed a flow like you have? If that is the case then could you report back if it indeed doesn't work for you (while it is for me). I've tested this out with Tomcat 5.0.28, Windows XP and JDK 1.4.2_04. Here is the testcase: - add a new global-forward to the struts-config.xml: <forward name="testredirect" path="/Locale.do?language=ru&page=/Welcome.do" redirect="true"/> - in the welcome.jsp change: <html:link action="/Locale?language=ja" useLocalEncoding="true">Japanese</html:link> to: <html:link action="/Locale?language=ja&forward=testredirect" useLocalEncoding="true">Japanese</html:link> With these changes and selecting the Japanese language on the welcome screen, the LocaleAction will be invoked (ActionURL) to set the Japanese language and than forward to the new testredirect forward. The testredirect forward redirects (as in your case the Filter.do) back to the LocaleAction but now for setting the Russian language (using query_string parameters) and finally forward to the Welcome screen again. The end result for the user is that the Locale is set to Russian instead of Japanese :-) This works without problems for me! I also turned on logging and to show it indeed works as expected, here is a trimmed part of the logging: ... PropertyMessageResources - loadLocale(nl) ... StrutsPortlet - process path: /Locale.do?language=ja&forward=testredirect, requestType: ACTION processForwardConfig(ForwardConfig[name=testredirect,path=/Locale.do?languag e=ru&page=/Welcome.do,redirect=true,... StrutsPortlet - action render redirected page: /Locale.do?language=ru&page=/Welcome.do navstate decoded=[[window:15,action:true,parameters:[_spage:[/Locale.do?language=ja&f orward=testredirect]]] navstate decoded=[[window:15,mode:view,state:normal,parameters:[_kra:[1],_spage:[/Loc ale.do?language=ru&page=/Welcome.do]]] StrutsPortlet - process path: /Locale.do?language=ru&page=/Welcome.do, requestType: VIEW processForwardConfig(ForwardConfig[name=null,path=/Welcome.do,redirect=false ,... ... PropertyMessageResources - loadLocale(ru) Regards, Ate Colin O'Toole wrote: > Hi Ate, > > I had some time to take a look at this yesterday and the situation is: > > PortletServletRequestWrapper now extends HttpServletRequestWrapper rather > than DispatchedHttpServletRequestWrapper. The > DispatchedHttpServletRequestWrapper constructor accepts the queryString from > the path and the parameters were parsed into a map. The params could then > be retrieved by calling getParameter(), getParameterNames() etc. > HttpServletRequestWrapper doesn't make the original params available in the > same way. > > I modified the code from the head to make PortletServletRequestWrapper > extend DispatchedHttpServletRequestWrapper once more (and obviously restore > DispatchedHttpServletRequestWrapper to the > org.apache.portals.bridges.struts.util package from where it was deleted). > My app now works correctly as before. > > I'm sure DispatchedHttpServletRequestWrapper was removed for a reason, so > this is likely no more than a temporary solution. > > Hope this helps, > > Colin. > > >>Colin, I will try to look at you problem later this evening or >>otherwise tomorrow evening. >> >>Ate >> >>Colin O'Toole wrote: >> >>>Hi all, >>> >>>I was using Struts portlet 0.2 with my app and it was working fine, I've >>>upgraded to the latest version from CVS and I'm now losing request >>>parameters. >>> >>>I have a action that is returning an ActionRedirect (a subclass of >>>ActionForward used for redirects) to a new action. Some parameters are >>>being added to the ActionRedirect. So it looks like this: >>> >>>(1) ViewAction.do has a submit to Filter.do (This is a portlet >> >>action URL) >> >>>(2) Filter.do does a redirect (with parameters) to ViewAction.do >>>(3) PopulateForm in ViewAction.do calls getParameter(XXX) which returns >>>null. >>> >>>In Struts-portlet 0.2, the PortletRequestObject object in Step >> >>(3) contains: >> >>>- An ApplicationContextFacade >>>- A Map of parameters containing the params from the redirect. >>>- A ServletRequestImpl >>> >>>In The latest version, the PortletRequestObject object in Step >> >>(3) contains: >> >>>- An ApplicationContextFacade >>>- No parameter map! >>>- A ServletRequestImpl. This contains a >> >>ApplicationHttpRequestObject. The >> >>>queryParamString member of the ApplicationHttpRequestObject >> >>holds the params >> >>>from the redirect. In Struts-portlet 0.2 this QueryParamString is null. >>> >>>So something has changed between 0.2 and now that has broken my >> >>app - I'm >> >>>unsure if this is a struts-portlet bug or whether I need to do something >>>extra to make this work. >>> >>>Any help would be appreciated, >>> >>>Colin. >>> >>> >>>--------------------------------------------------------------------- >>>To unsubscribe, e-mail: [EMAIL PROTECTED] >>>For additional commands, e-mail: [EMAIL PROTECTED] >>> >>> >>> >>> >>> >> >> >>--------------------------------------------------------------------- >>To unsubscribe, e-mail: [EMAIL PROTECTED] >>For additional commands, e-mail: [EMAIL PROTECTED] >> > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
