Colin, Your quick fix didn't work for me. Perhaps my flow is wrong. Here is what I am doing.
Displaying the View page (/myaction.do). Clicking the edit icon to go to the Edit page (/editmyaction.do). Then after hitting save on the edit page, I have to tell it to go back to the view page by doing this in the action class: actionResponse.setPortletMode(PortletMode.VIEW); It returns to the View page correctly (like it always has). Clicking on the edit button simply refreshes the view page, instead of taking me back to the edit screen. This is the same result as before I applied you fix. Have I done something differently than you? Thanks, -- Jeff On Thu, 10 Mar 2005 11:44:15 -0000, Colin O'Toole <[EMAIL PROTECTED]> wrote: > 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] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
