Re: Struts bridge, lost request parameters
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
> >>>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
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;
}
(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 == nul
RE: J2 - jstl - Expressions are not allowed
Amit, I just had that problem too. In my case it was because I was using the Servlet 2.4 spec. I don't know the details behind what changed in the JSTL from. I change the declaration in my web.xml header from: http://java.sun.com/xml/ns/j2ee"; xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"; xsi:schemaLocation="http://java.sun.com/xml/ns/j2ee http://java.sun.com/xml/ns/j2ee/web-app_2_4.xsd";> To http://java.sun.com/dtd/web-app_2_3.dtd";> I was fine after that. Hope that helps, - Doug -Original Message- From: Shah Amit [mailto:[EMAIL PROTECTED] Sent: Wednesday, March 09, 2005 2:02 PM To: jetspeed-user@jakarta.apache.org Subject: J2 - jstl - Expressions are not allowed Hi, I created my own portlet, and I am trying to use expressions in jstl but they are failing saying that they are not allowed. I had to go to the "c.tld" file and change "false" to "true" to allow those. Can someone please tell me what I am doing wrong ... I noticed that lot of sample applications of jetspeed use expressions, and they dont have to do this ... Thanks, Amit - 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
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: Why use Preferences for storing User Attributes?
Hi Frank, I understand a little bit of that part. I am in no way an expert but I will tell you what I understand. Say a user has --- prefName1=prefValue1 prefName2=prefValue2 In this case, prefName1 and prefName2 will be stored in PREFS_PROPERTY_KEY and prefValue1 and prefValue2 will be stored in PREFS_PROPERTY_VALUE. I have found that I will be able to live with this much knowledge because I can store my preferences in these tables, and I can retrieve them in my portlet. Hope that helps, Amit Original Message Follows From: "Frank Villarreal" <[EMAIL PROTECTED]> Reply-To: "Jetspeed Users List" To: "Jetspeed Users List" Subject: Why use Preferences for storing User Attributes? Date: Wed, 9 Mar 2005 15:01:18 -0600 Hello all. As I'm trying to integrate a legacy user database with J2's "SPI", I'm discovering all sorts of, shall we say ... stumbling blocks :-). I do understand the premise of how a User's attributes are accessed through the Request object ... however, I'm finding it incredibly unintuitive to decipher the J2 database structure (specifically user attribute instance values). Can someone please explain to me the purposes of the following specific tables ... and how they store user attribute values? - PREFERENCE_VALUE - PREFS_NODE - PREFS_NODE_PROPERTY_KEY - PREFS_PROPERTY_KEY - PREFS_PROPERTY_VALUE I have noted that the table "USER_ATTRIBUTE" stores the dynamic attribute names, but I'm trying to figure out how to "store instances" of attributes for individual users. Additionally, I do have a few "non-standard" attribute fields I'd like to store for each user ... and have no idea (from reading the docs or examining the DB model) of how to accomplish this. Any reason as to why a simple USER_ATTRIBUTE_VALUE table wasn't used instead? Being that a web site "User" is one of the central objects in a portal, seems to me that it would be best if customization of this aspect were kept simple? Just my 2 cents. Any insight would be greatly appreciated. - Frank - 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]
Why use Preferences for storing User Attributes?
Hello all. As I'm trying to integrate a legacy user database with J2's "SPI", I'm discovering all sorts of, shall we say ... stumbling blocks :-). I do understand the premise of how a User's attributes are accessed through the Request object ... however, I'm finding it incredibly unintuitive to decipher the J2 database structure (specifically user attribute instance values). Can someone please explain to me the purposes of the following specific tables ... and how they store user attribute values? - PREFERENCE_VALUE - PREFS_NODE - PREFS_NODE_PROPERTY_KEY - PREFS_PROPERTY_KEY - PREFS_PROPERTY_VALUE I have noted that the table "USER_ATTRIBUTE" stores the dynamic attribute names, but I'm trying to figure out how to "store instances" of attributes for individual users. Additionally, I do have a few "non-standard" attribute fields I'd like to store for each user ... and have no idea (from reading the docs or examining the DB model) of how to accomplish this. Any reason as to why a simple USER_ATTRIBUTE_VALUE table wasn't used instead? Being that a web site "User" is one of the central objects in a portal, seems to me that it would be best if customization of this aspect were kept simple? Just my 2 cents. Any insight would be greatly appreciated. - Frank - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: J2 - jstl - Expressions are not allowed
Thanks a lot Doug. That did fix my problem. Amit Original Message Follows From: Doug Schnelzer <[EMAIL PROTECTED]> Reply-To: [EMAIL PROTECTED] To: Jetspeed Users List Subject: Re: J2 - jstl - Expressions are not allowed Date: Wed, 9 Mar 2005 15:15:16 -0500 Amit, I just had that problem too. In my case it was because I was using the Servlet 2.4 spec. I don't know the details behind what changed in the JSTL from 2.3 to 2.4. I change the declaration in my web.xml header from: http://java.sun.com/xml/ns/j2ee"; xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"; xsi:schemaLocation="http://java.sun.com/xml/ns/j2ee http://java.sun.com/xml/ns/j2ee/web-app_2_4.xsd";> To http://java.sun.com/dtd/web-app_2_3.dtd";> I was fine after that. Hope that helps, - Doug On Wed, 09 Mar 2005 14:02:03 -0500, Shah Amit <[EMAIL PROTECTED]> wrote: > Hi, > > I created my own portlet, and I am trying to use expressions in jstl but > they are failing saying that they are not allowed. > > I had to go to the "c.tld" file and change > "false" to "true" to > allow those. > > Can someone please tell me what I am doing wrong ... I noticed that lot of > sample applications of jetspeed use expressions, and they dont have to do > this ... > > Thanks, > Amit > > - > 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: J2 - jstl - Expressions are not allowed
Amit, I just had that problem too. In my case it was because I was using the Servlet 2.4 spec. I don't know the details behind what changed in the JSTL from 2.3 to 2.4. I change the declaration in my web.xml header from: http://java.sun.com/xml/ns/j2ee"; xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"; xsi:schemaLocation="http://java.sun.com/xml/ns/j2ee http://java.sun.com/xml/ns/j2ee/web-app_2_4.xsd";> To http://java.sun.com/dtd/web-app_2_3.dtd";> I was fine after that. Hope that helps, - Doug On Wed, 09 Mar 2005 14:02:03 -0500, Shah Amit <[EMAIL PROTECTED]> wrote: > Hi, > > I created my own portlet, and I am trying to use expressions in jstl but > they are failing saying that they are not allowed. > > I had to go to the "c.tld" file and change > "false" to "true" to > allow those. > > Can someone please tell me what I am doing wrong ... I noticed that lot of > sample applications of jetspeed use expressions, and they dont have to do > this ... > > Thanks, > Amit > > - > 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]
J2 - jstl - Expressions are not allowed
Hi, I created my own portlet, and I am trying to use expressions in jstl but they are failing saying that they are not allowed. I had to go to the "c.tld" file and change "false" to "true" to allow those. Can someone please tell me what I am doing wrong ... I noticed that lot of sample applications of jetspeed use expressions, and they dont have to do this ... Thanks, Amit - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Struts bridge, lost request parameters
Hi Jeff,
You're welcome. If it causes any problems for you please post them here. I
think it's OK but I'm no portlet expert so it could break something! Ate
will be able to tell us for sure.
Colin.
> -Original Message-
> From: Jeff Sheets [mailto:[EMAIL PROTECTED]
> Sent: 09 March 2005 14:13
> To: Jetspeed Users List
> Subject: Re: Struts bridge, lost request parameters
>
>
> Hey Colin,
>
> I'll try out your "quick fix" for the edit page bug. We have really
> needed this fixed, and I was stumped on what was wrong, so thank you
> very much!
>
> -- Jeff
>
> On Wed, 9 Mar 2005 10:44:22 -, Colin O'Toole
> <[EMAIL PROTECTED]> wrote:
> > Hi Ate,
> >
> > This is OT, but there is another problem I have fixed locally.
> This is the
> > edit page problem reported originally reported by Jeff Sheets.
> The problem
> > is that when a submit is performed from an edit page, pressing
> the button to
> > change to view mode doesn't work anymore.
> >
> > The problem occurs in StrutsPortlet when the defaultPage (from the
> > portlet.xml) is overridden by the pageURL value from the
> StrutsPortletURL.
> > This mechanism doesn't take into account the fact that the
> portlet mode may
> > have changed. So what happens is that clicking the icon to go
> to VIEW mode
> > issues a doView(), which calls processRequest(), which pulls
> the _edit_ url
> > from the StrutsPortletURL and uses it instead of the ViewPage
> url specified
> > in portlet.xml.
> >
> > I needed a fix for a demo, so what I did was:
> >
> > (1) In StrutsPortletURL v1.4. Add a portlet mode.
> >
> > public static final String PORTLETMODE = "_mode";
> >
> > - Line 61 changes from this:
> >
> > if (actionURL)
> > {
> > String originURL = request.getParameter(PAGE);
> > if (originURL != null)
> > portletURL.setParameter(ORIGIN, originURL);
> > }
> > return portletURL;
> > }
> >
> > - To this:
> >
> > if (actionURL)
> > {
> > String originURL = request.getParameter(PAGE);
> > if (originURL != null)
> > portletURL.setParameter(ORIGIN, originURL);
> > }
> >
> > // Add the portlet mode to the request, we will only
> use the pageURL param
> > to override the
> > // default page if the portlet mode for this URL is the
> same as the current
> > mode when
> > // StrutsPortlet.processRequest() is executed
> > PortletRequest portletRequest =
> > (PortletRequest)request.getAttribute("javax.portlet.request");
> > String portletMode = portletRequest.getPortletMode().toString();
> > log.debug("portletMode is: " + portletMode);
> > portletURL.setParameter(PORTLETMODE, portletMode);
> >
> > return portletURL;
> > }
> >
> > (2) In StrutsPortlet v1.12. If there is a pageURL in the
> request, only use
> > it if the mode associated with it is the same as the current
> portlet mode:
> >
> > - Line 313 changes from
> >
> > String path = null;
> > String pageURL = request.getParameter(StrutsPortletURL.PAGE);
> > if (pageURL == null)
> > path = defaultPage
> > else
> > {
> > path = pageURL;
> > }
> >
> > - To:
> >
> > String path = null;
> > String pageURL = request.getParameter(StrutsPortletURL.PAGE);
> > String portletModeFromURL =
> > request.getParameter(StrutsPortletURL.PORTLETMODE);
> > String portletModeCurrent = request.getPortletMode().toString();
> > log.debug("portletModeFromURL: " + portletModeFromURL + ",
> > portletModeCurrent: " + portletModeCurrent);
> > if (pageURL == null) {
> > log.debug("pageURL from request is null, using default page: " +
> > defaultPage);
> > path = defaultPage;
> > }
> > else {
> > // only use the pageURL if the portlet mode associated
> with it is the same
> > as the
> > // portlet mode for the current request
> > if(( portletModeFromURL != null) &&
> > (portletModeFromURL.equalsIgnoreCase(portletModeCurrent))) {
> > log.debug("pageURL from request is:" + pageURL);
> > path = pageURL;
> > }
> > else {
> > log.debug("Not using pageURL as portlet mode has 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).setRen
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 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
RE: Struts bridge, lost request parameters
Hi Ate,
This is OT, but there is another problem I have fixed locally. This is the
edit page problem reported originally reported by Jeff Sheets. The problem
is that when a submit is performed from an edit page, pressing the button to
change to view mode doesn't work anymore.
The problem occurs in StrutsPortlet when the defaultPage (from the
portlet.xml) is overridden by the pageURL value from the StrutsPortletURL.
This mechanism doesn't take into account the fact that the portlet mode may
have changed. So what happens is that clicking the icon to go to VIEW mode
issues a doView(), which calls processRequest(), which pulls the _edit_ url
from the StrutsPortletURL and uses it instead of the ViewPage url specified
in portlet.xml.
I needed a fix for a demo, so what I did was:
(1) In StrutsPortletURL v1.4. Add a portlet mode.
public static final String PORTLETMODE = "_mode";
- Line 61 changes from this:
if (actionURL)
{
String originURL = request.getParameter(PAGE);
if (originURL != null)
portletURL.setParameter(ORIGIN, originURL);
}
return portletURL;
}
- To this:
if (actionURL)
{
String originURL = request.getParameter(PAGE);
if (originURL != null)
portletURL.setParameter(ORIGIN, originURL);
}
// Add the portlet mode to the request, we will only use the pageURL
param
to override the
// default page if the portlet mode for this URL is the same as the
current
mode when
// StrutsPortlet.processRequest() is executed
PortletRequest portletRequest =
(PortletRequest)request.getAttribute("javax.portlet.request");
String portletMode = portletRequest.getPortletMode().toString();
log.debug("portletMode is: " + portletMode);
portletURL.setParameter(PORTLETMODE, portletMode);
return portletURL;
}
(2) In StrutsPortlet v1.12. If there is a pageURL in the request, only use
it if the mode associated with it is the same as the current portlet mode:
- Line 313 changes from
String path = null;
String pageURL = request.getParameter(StrutsPortletURL.PAGE);
if (pageURL == null)
path = defaultPage
else
{
path = pageURL;
}
- To:
String path = null;
String pageURL = request.getParameter(StrutsPortletURL.PAGE);
String portletModeFromURL =
request.getParameter(StrutsPortletURL.PORTLETMODE);
String portletModeCurrent = request.getPortletMode().toString();
log.debug("portletModeFromURL: " + portletModeFromURL + ",
portletModeCurrent: " + portletModeCurrent);
if (pageURL == null) {
log.debug("pageURL from request is null, using default page: " +
defaultPage);
path = defaultPage;
}
else {
// only use the pageURL if the portlet mode associated with it is the
same
as the
// portlet mode for the current request
if(( portletModeFromURL != null) &&
(portletModeFromURL.equalsIgnoreCase(portletModeCurrent))) {
log.debug("pageURL from request is:" + pageURL);
path = pageURL;
}
else {
log.debug("Not using pageURL as portlet mode has changed from "
+ portletModeFromURL + " to " + portletModeCurrent);
path = defaultPage;
}
}
- Line 394 changes from:
if (pageURL != null)
{
if (renderURL == null && log.isWarnEnabled())
log.warn("Warning: Using the original action URL for render URL: "
+pageURL+".\nA redirect should have been issued.");
((ActionResponse) response).setRenderParameter(StrutsPortletURL.PAGE,
pageURL);
}
- To:
if (pageURL != null)
{
if (renderURL == null && log.isWarnEnabled())
log.warn("Warning: Using the original action URL for render URL: "
+pageURL+".\nA redirect should have been issued.");
((ActionResponse) response).setRenderParameter(StrutsPortletURL.PAGE,
pageURL);
// NEW - add portletMode to render response
((ActionResponse)
response).setRenderParameter(StrutsPortletURL.PORTLETMODE,
portletModeFromURL);
}
As I said this is a quick fix. I'd like to keep in sync with your
'official' releases if possible. Can you tell me if this bug is on your hit
list for the next release?
Colin.
> -Original Message-
> From: Colin O'Toole [mailto:[EMAIL PROTECTED]
> Sent: 09 March 2005 10:08
> To: Jetspeed Users List
> Subject: RE: Struts bridge, lost request parameters
>
>
> Hi Ate,
>
> I had some time to take a look at this yesterday and the situation is:
>
> PortletServletRequestWrapper now extends HttpServletRequestWrapper rather
> than DispatchedHttpServletRequestWrapper. The
> DispatchedHttpServletRequestWrapper constructor accepts the
> queryString from
> the path and the parameters 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 th
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]
