Re: Struts bridge, lost request parameters

Ate Douma Wed, 09 Mar 2005 15:19:16 -0800

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]

Re: Struts bridge, lost request parameters

Reply via email to