Re: Struts bridge, lost request parameters

[Ate Douma]

Jeff Sheets wrote:
Colin,
My apologies, because your fix does work for me!!!  Thank you!
My actual code was:
actionResponse.setPortletMode(PortletMode.VIEW);
return mapping.findForward(FORWARD_VIEW);
As this worked before your fix to at least return me to the View page.
 But now we need to forward back to the edit page, so that when we
return to the edit mode we get the page correctly.  So my code now
looks like this:
actionResponse.setPortletMode(PortletMode.VIEW);
return mapping.findForward(FORWARD_EDIT);
Thank you very much for your help!  Ate, hopefully this can be
committed to the baseline soon?
It will ;-)
Probably sometime next week.
-- Jeff
On Thu, 10 Mar 2005 16:18:14 -, Colin O'Toole
<[EMAIL PROTECTED]> wrote:
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 tim

Re: Struts bridge, lost request parameters

[Jeff Sheets]

Colin,

My apologies, because your fix does work for me!!!  Thank you!

My actual code was:
actionResponse.setPortletMode(PortletMode.VIEW);
return mapping.findForward(FORWARD_VIEW);

As this worked before your fix to at least return me to the View page.
 But now we need to forward back to the edit page, so that when we
return to the edit mode we get the page correctly.  So my code now
looks like this:
actionResponse.setPortletMode(PortletMode.VIEW);
return mapping.findForward(FORWARD_EDIT);

Thank you very much for your help!  Ate, hopefully this can be
committed to the baseline soon?
-- Jeff

On Thu, 10 Mar 2005 16:18:14 -, Colin O'Toole
<[EMAIL PROTECTED]> wrote:
> 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 no

RE: Struts bridge, lost request parameters

[Colin O'Toole]

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

[Jeff Sheets]

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 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
> >

RE: Struts bridge, lost request parameters

[Colin O'Toole]

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

[Colin O'Toole]

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

[Ate Douma]

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:
   
- 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
o

RE: Struts bridge, lost request parameters

[Colin O'Toole]

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

[Jeff Sheets]

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 -, 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
> >>>PortletReq

Re: Struts bridge, lost request parameters

[Ate Douma]

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;
}
(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

Re: Struts bridge, lost request parameters

[Ate Douma]

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?language=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&forward=testredirect]]]
navstate 
decoded=[[window:15,mode:view,state:normal,parameters:[_kra:[1],_spage:[/Locale.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

RE: Struts bridge, lost request parameters

[Colin O'Toole]

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

[Jeff Sheets]

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 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 portle

RE: Struts bridge, lost request parameters

[Colin O'Toole]

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

[Colin O'Toole]

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]

Re: Struts bridge, lost request parameters

[Ate Douma]

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]

Struts bridge, lost request parameters

[Colin O'Toole]

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]