Ah! OK I will try this but it will have to wait until tomorrow. because of time constraints I may stick with what I have and do a wholesale upgrade once M2 is released.
Thanks for the help! Colin. -----Original Message----- From: Ate Douma [mailto:[EMAIL PROTECTED] Sent: 10 March 2005 11:30 To: Jetspeed Users List Subject: Re: Struts bridge, lost request parameters Colin O'Toole wrote: > 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. Now we are getting somewhere: you are running Jetspeed 2 M1... I'm not sure but I think that will be the reason. I don't test or develop against M1 anymore. As we are approaching a M2 release very soon, I suggest you try your application with the latest CVS HEAD if possible. > > 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] > > > > > --------------------------------------------------------------------- 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]
