RE: Struts bridge, lost request parameters
Hi Jeff, That is similar to what I'm doing except that I don't make the portlet automatically return to the view mode after submitting an edit page change. I stay in edit until the user explicitly clicks the view button. If you enable debug logging you should get some detailed information about what is happening when you click the edit button. I also found that remote debugging the app and setting breakpoints in StrutsPortlet.processRequest() made it easy to figure out what was going on. I will add the actionResponse.setPortletMode(PortletMode.VIEW); to my edit action code and see if it breaks anything. Might tae me a while to get around to it though :-) Cheers, Colin. -Original Message- From: Jeff Sheets [mailto:[EMAIL PROTECTED] Sent: 10 March 2005 15:57 To: Jetspeed Users List Subject: Re: Struts bridge, lost request parameters 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 -, 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 sim
RE: Struts bridge, lost request parameters
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: > > path="/Locale.do?language=ru&page=/Welcome.do" redirect="true"/> > > - in the welcome.jsp change: > > useLocalEncoding="true">Japanese >to: > useLocalEncoding="true">Japanese > > 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=[[windo
RE: Struts bridge, lost request parameters
Yep that sounds like a good idea. I'm just wondering: is it possible that because of some action in an edit page the stored view page Url might no longer be valid? Can't think of a good example off the top of my head though :-) Colin. -Original Message- From: Ate Douma [mailto:[EMAIL PROTECTED] Sent: 09 March 2005 23:19 To: Jetspeed Users List Subject: Re: Struts bridge, lost request parameters Colin O'Toole wrote: > Hi Jeff, > > You're welcome. If it causes any problems for you please post them here. I > think it's OK but I'm no portlet expert so it could break something! Ate > will be able to tell us for sure. Sure ;-) I think your fix should do the trick indeed. And I don't think it breaks anything! I'm not sure I'm going to implement it (only) like this though. One thing not possible with this solution is "remembering" the PageURL you leave when switching to another mode. If you come back to the (or a) previous mode, you always re-enter with its defaultPage. I'm thinking of saving the last PageURL for each mode (if unequal to its defaultPage) in a special session scoped object and restoring it when the (or a) previously used mode is re-entered. Probably this should be configurable too (using an init parameter) so your 'light' solution can also be used. What do you think? And Jeff, is this indeed a/the solution for your problem? Regards, Ate > > Colin. > > >>-Original Message- >>From: Jeff Sheets [mailto:[EMAIL PROTECTED] >>Sent: 09 March 2005 14:13 >>To: Jetspeed Users List >>Subject: Re: Struts bridge, lost request parameters >> >> >>Hey Colin, >> >>I'll try out your "quick fix" for the edit page bug. We have really >>needed this fixed, and I was stumped on what was wrong, so thank you >>very much! >> >>-- Jeff >> >>On Wed, 9 Mar 2005 10:44:22 -, Colin O'Toole >><[EMAIL PROTECTED]> wrote: >> >>>Hi Ate, >>> >>>This is OT, but there is another problem I have fixed locally. >> >>This is the >> >>>edit page problem reported originally reported by Jeff Sheets. >> >>The problem >> >>>is that when a submit is performed from an edit page, pressing >> >>the button to >> >>>change to view mode doesn't work anymore. >>> >>>The problem occurs in StrutsPortlet when the defaultPage (from the >>>portlet.xml) is overridden by the pageURL value from the >> >>StrutsPortletURL. >> >>>This mechanism doesn't take into account the fact that the >> >>portlet mode may >> >>>have changed. So what happens is that clicking the icon to go >> >>to VIEW mode >> >>>issues a doView(), which calls processRequest(), which pulls >> >>the _edit_ url >> >>>from the StrutsPortletURL and uses it instead of the ViewPage >> >>url specified >> >>>in portlet.xml. >>> >>>I needed a fix for a demo, so what I did was: >>> >>>(1) In StrutsPortletURL v1.4. Add a portlet mode. >>> >>>public static final String PORTLETMODE = "_mode"; >>> >>>- Line 61 changes from this: >>> >>>if (actionURL) >>>{ >>>String originURL = request.getParameter(PAGE); >>>if (originURL != null) >>>portletURL.setParameter(ORIGIN, originURL); >>>} >>>return portletURL; >>>} >>> >>>- To this: >>> >>>if (actionURL) >>>{ >>>String originURL = request.getParameter(PAGE); >>> if (originURL != null) >>>portletURL.setParameter(ORIGIN, originURL); >>>} >>> >>>// Add the portlet mode to the request, we will only >> >>use the pageURL param >> >>>to override the >>>// default page if the portlet mode for this URL is the >> >>same as the current >> >>>mode when >>>// StrutsPortlet.processRequest() is executed >>>PortletRequest portletRequest = >>>(PortletRequest)request.getAttribute("javax.portlet.request"); >>>String portletMode = portletRequest.getPortletMode().toString(); >>>log.debug("portletMode is: " + portletMode); >>>portletURL.setParameter(PORTLETMODE, portletMode); >>> >>>return portletURL; >>>} >>> >
RE: Struts bridge, lost request parameters
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: - in the welcome.jsp change: Japanese to: Japanese 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 &g
RE: Struts bridge, lost request parameters
Hi Jeff, You're welcome. If it causes any problems for you please post them here. I think it's OK but I'm no portlet expert so it could break something! Ate will be able to tell us for sure. Colin. > -Original Message- > From: Jeff Sheets [mailto:[EMAIL PROTECTED] > Sent: 09 March 2005 14:13 > To: Jetspeed Users List > Subject: Re: Struts bridge, lost request parameters > > > Hey Colin, > > I'll try out your "quick fix" for the edit page bug. We have really > needed this fixed, and I was stumped on what was wrong, so thank you > very much! > > -- Jeff > > On Wed, 9 Mar 2005 10:44:22 -, Colin O'Toole > <[EMAIL PROTECTED]> wrote: > > Hi Ate, > > > > This is OT, but there is another problem I have fixed locally. > This is the > > edit page problem reported originally reported by Jeff Sheets. > The problem > > is that when a submit is performed from an edit page, pressing > the button to > > change to view mode doesn't work anymore. > > > > The problem occurs in StrutsPortlet when the defaultPage (from the > > portlet.xml) is overridden by the pageURL value from the > StrutsPortletURL. > > This mechanism doesn't take into account the fact that the > portlet mode may > > have changed. So what happens is that clicking the icon to go > to VIEW mode > > issues a doView(), which calls processRequest(), which pulls > the _edit_ url > > from the StrutsPortletURL and uses it instead of the ViewPage > url specified > > in portlet.xml. > > > > I needed a fix for a demo, so what I did was: > > > > (1) In StrutsPortletURL v1.4. Add a portlet mode. > > > > public static final String PORTLETMODE = "_mode"; > > > > - Line 61 changes from this: > > > > if (actionURL) > > { > > String originURL = request.getParameter(PAGE); > > if (originURL != null) > > portletURL.setParameter(ORIGIN, originURL); > > } > > return portletURL; > > } > > > > - To this: > > > > if (actionURL) > > { > > String originURL = request.getParameter(PAGE); > > if (originURL != null) > > portletURL.setParameter(ORIGIN, originURL); > > } > > > > // Add the portlet mode to the request, we will only > use the pageURL param > > to override the > > // default page if the portlet mode for this URL is the > same as the current > > mode when > > // StrutsPortlet.processRequest() is executed > > PortletRequest portletRequest = > > (PortletRequest)request.getAttribute("javax.portlet.request"); > > String portletMode = portletRequest.getPortletMode().toString(); > > log.debug("portletMode is: " + portletMode); > > portletURL.setParameter(PORTLETMODE, portletMode); > > > > return portletURL; > > } > > > > (2) In StrutsPortlet v1.12. If there is a pageURL in the > request, only use > > it if the mode associated with it is the same as the current > portlet mode: > > > > - Line 313 changes from > > > > String path = null; > > String pageURL = request.getParameter(StrutsPortletURL.PAGE); > > if (pageURL == null) > > path = defaultPage > > else > > { > > path = pageURL; > > } > > > > - To: > > > > String path = null; > > String pageURL = request.getParameter(StrutsPortletURL.PAGE); > > String portletModeFromURL = > > request.getParameter(StrutsPortletURL.PORTLETMODE); > > String portletModeCurrent = request.getPortletMode().toString(); > > log.debug("portletModeFromURL: " + portletModeFromURL + ", > > portletModeCurrent: " + portletModeCurrent); > > if (pageURL == null) { > > log.debug("pageURL from request is null, using default page: " + > > defaultPage); > > path = defaultPage; > > } > > else { > > // only use the pageURL if the portlet mode associated > with it is the same > > as the > > // portlet mode for the current request > > if(( portletModeFromURL != null) && > > (portletModeFromURL.equalsIgnoreCase(portletModeCurrent))) { > > log.debug("pageURL from request is:" + pageURL); > > path = pageURL; > > } > > else { > > log.debug("Not using pageURL as portlet mode has cha
RE: Struts bridge, lost request parameters
Hi Ate, This is OT, but there is another problem I have fixed locally. This is the edit page problem reported originally reported by Jeff Sheets. The problem is that when a submit is performed from an edit page, pressing the button to change to view mode doesn't work anymore. The problem occurs in StrutsPortlet when the defaultPage (from the portlet.xml) is overridden by the pageURL value from the StrutsPortletURL. This mechanism doesn't take into account the fact that the portlet mode may have changed. So what happens is that clicking the icon to go to VIEW mode issues a doView(), which calls processRequest(), which pulls the _edit_ url from the StrutsPortletURL and uses it instead of the ViewPage url specified in portlet.xml. I needed a fix for a demo, so what I did was: (1) In StrutsPortletURL v1.4. Add a portlet mode. public static final String PORTLETMODE = "_mode"; - Line 61 changes from this: if (actionURL) { String originURL = request.getParameter(PAGE); if (originURL != null) portletURL.setParameter(ORIGIN, originURL); } return portletURL; } - To this: if (actionURL) { String originURL = request.getParameter(PAGE); if (originURL != null) portletURL.setParameter(ORIGIN, originURL); } // Add the portlet mode to the request, we will only use the pageURL param to override the // default page if the portlet mode for this URL is the same as the current mode when // StrutsPortlet.processRequest() is executed PortletRequest portletRequest = (PortletRequest)request.getAttribute("javax.portlet.request"); String portletMode = portletRequest.getPortletMode().toString(); log.debug("portletMode is: " + portletMode); portletURL.setParameter(PORTLETMODE, portletMode); return portletURL; } (2) In StrutsPortlet v1.12. If there is a pageURL in the request, only use it if the mode associated with it is the same as the current portlet mode: - Line 313 changes from String path = null; String pageURL = request.getParameter(StrutsPortletURL.PAGE); if (pageURL == null) path = defaultPage else { path = pageURL; } - To: String path = null; String pageURL = request.getParameter(StrutsPortletURL.PAGE); String portletModeFromURL = request.getParameter(StrutsPortletURL.PORTLETMODE); String portletModeCurrent = request.getPortletMode().toString(); log.debug("portletModeFromURL: " + portletModeFromURL + ", portletModeCurrent: " + portletModeCurrent); if (pageURL == null) { log.debug("pageURL from request is null, using default page: " + defaultPage); path = defaultPage; } else { // only use the pageURL if the portlet mode associated with it is the same as the // portlet mode for the current request if(( portletModeFromURL != null) && (portletModeFromURL.equalsIgnoreCase(portletModeCurrent))) { log.debug("pageURL from request is:" + pageURL); path = pageURL; } else { log.debug("Not using pageURL as portlet mode has changed from " + portletModeFromURL + " to " + portletModeCurrent); path = defaultPage; } } - Line 394 changes from: if (pageURL != null) { if (renderURL == null && log.isWarnEnabled()) log.warn("Warning: Using the original action URL for render URL: " +pageURL+".\nA redirect should have been issued."); ((ActionResponse) response).setRenderParameter(StrutsPortletURL.PAGE, pageURL); } - To: if (pageURL != null) { if (renderURL == null && log.isWarnEnabled()) log.warn("Warning: Using the original action URL for render URL: " +pageURL+".\nA redirect should have been issued."); ((ActionResponse) response).setRenderParameter(StrutsPortletURL.PAGE, pageURL); // NEW - add portletMode to render response ((ActionResponse) response).setRenderParameter(StrutsPortletURL.PORTLETMODE, portletModeFromURL); } As I said this is a quick fix. I'd like to keep in sync with your 'official' releases if possible. Can you tell me if this bug is on your hit list for the next release? Colin. > -Original Message- > From: Colin O'Toole [mailto:[EMAIL PROTECTED] > Sent: 09 March 2005 10:08 > To: Jetspeed Users List > Subject: RE: Struts bridge, lost request parameters > > > 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 we
RE: Struts bridge, lost request parameters
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]
Struts bridge, lost request parameters
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]
Jetspeed2 / struts app on Tomcat 5.5.4
Hi all, I have an install of a struts portlet on Tomcat using Jetspeed2 and the struts-portlet bridge. It works fine with 4.1 and 5.0.28. When I install Jetspeed with the same app on Tomcat 5.4.4 (with 1.4jdk compatibility) I get the following error when I access http://localhost:8080/jetspeed/portal. 2005-02-04 10:32:26,452 [http-8080-Processor24] DEBUG org.apache.jetspeed.aggregator.impl.PageAggregatorImpl - Rendering portlet fragment: [[name, bam::SummaryPortlet], [id, summary1]] 2005-02-04 10:32:27,249 [WORKER_5] DEBUG org.apache.jetspeed.aggregator.impl.Worker - Processing job for window :summary1 2005-02-04 10:32:27,249 [http-8080-Processor24] DEBUG org.apache.jetspeed.aggregator.impl.ContentDispatcherImpl - Waiting for content OID summary1 2005-02-04 10:32:27,249 [WORKER_5] DEBUG org.apache.jetspeed.aggregator.impl.RenderingJob - Rendering OID summary1 [EMAIL PROTECTED] [EMAIL PROTECTED] 2005-02-04 10:32:27,436 [WORKER_5] ERROR org.apache.jetspeed.factory.JetspeedPortletFactory - PortletFactory: Failed to load portlet org.apache.portals.bridges.struts.StrutsPortlet java.io.FileNotFoundException: Could not located portlet org.apache.portals.bridges.struts.StrutsPortlet in any classloader. at org.apache.jetspeed.factory.JetspeedPortletFactory.getPortlet(JetspeedPortle tFactory.java:173) at org.apache.jetspeed.factory.JetspeedPortletFactoryProxy.getPortlet(JetspeedP ortletFactoryProxy.java:71) at org.apache.jetspeed.container.JetspeedContainerServlet.doGet(JetspeedContain erServlet.java:221) at javax.servlet.http.HttpServlet.service(HttpServlet.java:689) at javax.servlet.http.HttpServlet.service(HttpServlet.java:802) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(Application FilterChain.java:237) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterCh ain.java:157) at org.apache.catalina.core.ApplicationDispatcher.invoke(ApplicationDispatcher. java:674) at org.apache.catalina.core.ApplicationDispatcher.doInclude(ApplicationDispatch er.java:576) at org.apache.catalina.core.ApplicationDispatcher.include(ApplicationDispatcher .java:501) at org.apache.jetspeed.container.invoker.ServletPortletInvoker.invoke(ServletPo rtletInvoker.java:213) at org.apache.jetspeed.container.invoker.ServletPortletInvoker.render(ServletPo rtletInvoker.java:124) at org.apache.pluto.PortletContainerImpl.renderPortlet(PortletContainerImpl.jav a:103) at org.apache.jetspeed.container.JetspeedPortletContainerWrapper.renderPortlet( JetspeedPortletContainerWrapper.java:88) at org.apache.jetspeed.aggregator.impl.RenderingJob.run(RenderingJob.java:109) at org.apache.jetspeed.aggregator.impl.Worker$1.run(Worker.java:171) at java.security.AccessController.doPrivileged(Native Method) at javax.security.auth.Subject.doAsPrivileged(Subject.java:437) at org.apache.jetspeed.aggregator.impl.Worker.run(Worker.java:165) The portals-bridges-struts jar is in the WEB-INF of the portlet webapp (bam). I'm unsure as to whether this is a Jetspeed2 or Tomcat problem, or just something obvious that I'm doing wrong. Any help would be appreciated. Thanks, Colin. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Portlets and filters
I believe you need to be running a servlet2.4 - compatible container and include the tags inside your element. See the thread below for details: http://www.mail-archive.com/jetspeed-user@jakarta.apache.org/msg14477.html -Original Message- From: Xavier Lawrence [mailto:[EMAIL PROTECTED] Sent: 21 January 2005 15:13 To: Jetspeed Users List Cc: Jetspeed Developers List Subject: Portlets and filters Hello, I have a working struts application that I am trying to change to a portlet. I was asking myself how were filters managed in the portlet world. I seem to have a slight problem with those, they seem to be not considered by the portlet. That is, the non-portlet webApp works fine, but the portlet struts app encounters problems because some filter methods don't seem to be called... Any help is appreciated on the subject. Below is a piece of my web.xml file XSLT Filter edu.rpi.sss.util.servlets.ConfiguredXSLTFilter debug 0 directoryBrowsingDisallowed no SvcI Filter edu.rpi.cct.uwcal.webcommon.UWCalSvciFilter debug 0 - 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]