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 -0000, 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 -0000, Colin O'Toole <[EMAIL PROTECTED]> wrote:
Ah! OK I will try this but it will have to wait until tomorrow. because
of
time constraints I may stick with what I have and do a wholesale upgrade once M2 is released.
Thanks for the help!
Colin.
-----Original Message----- From: Ate Douma [mailto:[EMAIL PROTECTED] Sent: 10 March 2005 11:30 To: Jetspeed Users List Subject: Re: Struts bridge, lost request parameters
Colin O'Toole wrote:
Hi Ate,
OK, I made the changes you detailed and tried this and what happens is:
(1) Clicking on link goes to LocaleAction (ActionUrl). Using remote debugging in eclipse with a breakpoint in LocaleAction.execute(), the PortletServletRequestWrapper object contains an ApplicationContextFacade
and
a ServletRequestImpl. The ServletRequestImpl contains an ApplicationHttpRequestObject. The queryParamString member of the ApplicationHttpRequestObject holds the params "language=ja&forward=testredirect". (This is what I saw in my example
also)
(2) In LocaleAction the following code is run:
target = request.getParameter(FORWARD);
This returns null - the parameter "forward=testredirect" is not found in
the
request. This causes the following code to be executed:
if (isBlank(target)) target = mapping.getParameter(); .... return mapping.findForward(target);
"target" is the default welcome global mapping from the
struts-config.xml,
so the WelcomeAction is called.
So in fact for me it appears that request params are being lost
wholesale -
irrespective of whether or not it is a redirect or a simple forward. I
am
using Tomcat 5.5.4, Windows XP, JDK 1.4.2_05, JetSpeed M1. I will try
later
today with Tomcat 5.0.28 which I also have.
Now we are getting somewhere: you are running Jetspeed 2 M1...
I'm not sure but I think that will be the reason. I don't test or develop against M1 anymore. As we are approaching a M2 release very soon, I suggest you
try
your application with the latest CVS HEAD if possible.
If I run the above code with the old version - which expressly parses
the
querystring in StrutsPortlet and passes it into PortletServletRequestWrapper, it works as you describe. I'm a bit
stumped
here. :-)
Can you help me understand where the params go in the new PortletServletRequestWrapper? In the old PortletServletRequestWrapper I could see that in DispatchedHttpServletRequestWrapper they were parsed
into
a map. I'm unsure as to where they end up now.
Thanks, Colin.
-----Original Message----- From: Ate Douma [mailto:[EMAIL PROTECTED] Sent: 09 March 2005 22:41 To: Jetspeed Users List Subject: Re: Struts bridge, lost request parameters
Colin,
I took some time to create a testcase with a similar flow as you
described
earlier. For this, I used the struts-demo as provided with Jetspeed-2. Could you please check if this is indeed a flow like you have? If that is the case then could you report back if it indeed doesn't work
for
you (while it is for me). I've tested this out with Tomcat 5.0.28, Windows
XP
and JDK 1.4.2_04.
Here is the testcase:
- add a new global-forward to the struts-config.xml:
<forward name="testredirect" path="/Locale.do?language=ru&page=/Welcome.do" redirect="true"/>
- in the welcome.jsp change:
<html:link action="/Locale?language=ja" useLocalEncoding="true">Japanese</html:link> to: <html:link action="/Locale?language=ja&forward=testredirect" useLocalEncoding="true">Japanese</html:link>
With these changes and selecting the Japanese language on the welcome screen, the LocaleAction will be invoked (ActionURL) to set the Japanese language and than
forward
to
the new testredirect forward. The testredirect forward redirects (as in your case the Filter.do) back
to
the LocaleAction but now for setting the Russian language (using query_string parameters) and finally forward to the Welcome screen again. The end result for the user is that the Locale is set to Russian instead
of
Japanese :-)
This works without problems for me! I also turned on logging and to show it indeed works as expected, here
is
a
trimmed part of the logging: ... PropertyMessageResources - loadLocale(nl) ... StrutsPortlet - process path:
/Locale.do?language=ja&forward=testredirect,
requestType: ACTION
processForwardConfig(ForwardConfig[name=testredirect,path=/Locale.do?languag
e=ru&page=/Welcome.do,redirect=true,... StrutsPortlet - action render redirected page: /Locale.do?language=ru&page=/Welcome.do navstate
decoded=[[window:15,action:true,parameters:[_spage:[/Locale.do?language=ja&f
orward=testredirect]]] navstate
decoded=[[window:15,mode:view,state:normal,parameters:[_kra:[1],_spage:[/Loc
ale.do?language=ru&page=/Welcome.do]]] StrutsPortlet - process path: /Locale.do?language=ru&page=/Welcome.do, requestType: VIEW
processForwardConfig(ForwardConfig[name=null,path=/Welcome.do,redirect=false
,... ... PropertyMessageResources - loadLocale(ru)
Regards, Ate
Colin O'Toole wrote:
Hi Ate,
I had some time to take a look at this yesterday and the situation is:
PortletServletRequestWrapper now extends HttpServletRequestWrapper
rather
than DispatchedHttpServletRequestWrapper. The DispatchedHttpServletRequestWrapper constructor accepts the queryString
from
the path and the parameters were parsed into a map. The params could
then
be retrieved by calling getParameter(), getParameterNames() etc. HttpServletRequestWrapper doesn't make the original params available in
the
same way.
I modified the code from the head to make PortletServletRequestWrapper extend DispatchedHttpServletRequestWrapper once more (and obviously
restore
DispatchedHttpServletRequestWrapper to the org.apache.portals.bridges.struts.util package from where it was
deleted).
My app now works correctly as before.
I'm sure DispatchedHttpServletRequestWrapper was removed for a reason,
so
this is likely no more than a temporary solution.
Hope this helps,
Colin.
Colin, I will try to look at you problem later this evening or otherwise tomorrow evening.
Ate
Colin O'Toole wrote:
Hi all,
I was using Struts portlet 0.2 with my app and it was working fine,
I've
upgraded to the latest version from CVS and I'm now losing request parameters.
I have a action that is returning an ActionRedirect (a subclass of ActionForward used for redirects) to a new action. Some parameters
are
being added to the ActionRedirect. So it looks like this:
(1) ViewAction.do has a submit to Filter.do (This is a portlet
action URL)
(2) Filter.do does a redirect (with parameters) to ViewAction.do (3) PopulateForm in ViewAction.do calls getParameter(XXX) which
returns
null.
In Struts-portlet 0.2, the PortletRequestObject object in Step
(3) contains:
- An ApplicationContextFacade - A Map of parameters containing the params from the redirect. - A ServletRequestImpl
In The latest version, the PortletRequestObject object in Step
(3) contains:
- An ApplicationContextFacade - No parameter map! - A ServletRequestImpl. This contains a
ApplicationHttpRequestObject. The
queryParamString member of the ApplicationHttpRequestObject
holds the params
from the redirect. In Struts-portlet 0.2 this QueryParamString is
null.
So something has changed between 0.2 and now that has broken my
app - I'm
unsure if this is a struts-portlet bug or whether I need to do
something
extra to make this work.
Any help would be appreciated,
Colin.
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
--------------------------------------------------------------------- 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]
