I had trouble testing this today, but hope to finish testing before
noon tomorrow.
-- Jeff


On Thu, 10 Mar 2005 00:19:05 +0100, Ate Douma <[EMAIL PROTECTED]> wrote:
> 
> 
> 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 -0000, 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 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 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]

Reply via email to