RequestDispatcher query string

[rraposa]

I am trying to do something very simple. I have the following code in my doView method:

String path ="/jsp/test.jsp?message=Thank you!";

getPortletContext().getRequestDispatcher(path).include(request,response);

According to the spec, this should make "message" available as a render parameter in test.jsp. I have looked at every type of request object available in test.jsp, and the parameter "message" is nowhere to be found. I think it should be a parameter of the renderRequest object.

Is what I am attempting to do even valid?

Thanks!

Rich

[rraposa]

Never mind - I just figured it out. The parameter from the query string passed in to the include() method is available in the HttpRequest object - the "request" object in the JSP page.

The following code in test.jsp shows two ways to display the "message" parameter:

<div class="portlet-section-body">

    <%= request.getParameter("message") %>

    <br/>

    <p>${request.message}</p>

</div>

This seems to contradict the JSR286 spec, which clearly states that query string parameters need to be aggregated as render parameters, and that these query parameters can override any previously defined render parameters.

[theute]

Can you please open a JIRA for a deeper look ?

If you arlready have a simple portlet that shows the defect it would be great to attach it to the Jira

Thanks !

Thomas.

[trong.tran]

Hi Rich,

As I understand in your case, the request object belongs RenderRequest class type and the request.getParameter method exactly returns the value of a render parameter.

So there is nothing wrong here :-)

[theute]

AFAIU, Rich says that this part of the spec isn't working:

*************

PLT.19.1.1 Query Strings in Request Dispatcher Paths

The getRequestDispatcher method of the PortletContext that creates

PortletRequestDispatcher objects using path information allows the optional

attachment of query string information to the path. For example, a Developer may obtain

a PortletRequestDispatcher by using the following code:

String path = "/raisons.jsp?orderno=5";

PortletRequestDispatcher rd = context.getRequestDispatcher(path);

rd.include(renderRequest, renderResponse);

Parameters specified in the query string used to create the PortletRequestDispatcher

must be aggregated with the portlet render parameters and take precedence over other

portlet render parameters of the same name passed to the included servlet or JSP. The

parameters associated with a PortletRequestDispatcher are scoped to apply only for

the duration of the include call.

*************

and <%= renderRequest.getParamter("message")%> in test.jsp doesn't return the value "Thank you!" in his case (I guess, I haven't tried)

[trong.tran]

i have just tried this and it still works well for me.

Waiting for Rich to confirm what exactly is his case

[rraposa]

It is possible that I just don't understand the difference between a render parameter and a request parameter. Suppose I have the following code in my render method:

request.setAttribute("reply", "No thanks");

String path = "/jsp/myform.jsp?reply=Thank you!";

getPortletContext().getRequestDispatcher(path).include(request, response);

According to the spec, the query string parameter "reply" should be aggregated with the other render parameters, and take precedence over render parameters with the same name. Here is what myform.jsp looks like:

<portlet:defineObjects/>

EL: ${reply}

Render request: <%= renderRequest.getParameter("reply") %>

Request: <%= request.getParameter("reply") %>

The output does not seem consistent with the spec:

EL: No thanks

Render request: null

Request: Thank you!

Notice the Expression Language for ${reply} is "No thanks", the renderRequest object doesn't have a parameter named "reply", but the HttpRequest object contains the overridden value. My question is: how come the renderRequest object does not contain a parameter named "reply" whose value is "Thank you!"? And how did the EL value of ${reply} end up being "No thanks"?

[trong.tran]

Yes, you are right. it was my misunderstanding and thanks for your clarification, Rich.

it looks like a bug in the tablib implementation for the portlet spec. Could you open a JIRA as Thomas asked ?

[rraposa]

I already did! Here it is:

https://issues.jboss.org/browse/GTNPORTAL-1750

Let me know if I can do anything to help.

Thanks!

Rich

[mwringe]

Parameters specified in the query string used to create the PortletRequestDispatcher

must be aggregated with the portlet render parameters and take precedence over other

portlet render parameters of the same name passed to the included servlet or JSP. The

parameters associated with a PortletRequestDispatcher are scoped to apply only for

the duration of the include call.

I am reading this as follows:

1) the PortletRequestDispatcher contains its own set of parameters (note: not the same thing as RenderRequest parameters)

2) the PortletRequestDispatcher's must contain the same parameters as the portlet render parameters ("... must be aggregated with the portlet render parameters...")

3) if the PortletRequestDispatcher's path contains query strings, those parameters must be added to the PortletRequestDispatcher's list of parameters and override any parameters added in step 2 from the portlet render parameters

I don't view this as a way to modify the RenderRequest parameters.

The way I view this is that the RenderRequest paramters will not change, but the Request parameters will (which is what seems to be the case with your tests).

[rraposa]

Matt,

Thanks for the response. I agree - adding a parameter to a query string doesn't change a RenderRequest parameter permanently, but it *should* change for the scope of the included JSP or Servlet. And if it's not a render parameter in the included JSP or servlet, then what is it?

An included JSP has access to render parameters, and the spec states that query string parameters must take precedence over existing render request parameters, at least for the scope of the JSP. I am either oversimplifying this or I'm missing something. Are you sure your statement #1 above is accurate? If it is, how are these PortletRequestDispatcher parameters accessed in the JSP? That might help me understand better.

Thanks for your help!

Rich

[mwringe]

Thanks for the response. I agree - adding a parameter to a query string doesn't change a RenderRequest parameter permanently, but it *should* change for the scope of the included JSP or Servlet. And if it's not a render parameter in the included JSP or servlet, then what is it?

I don't think it should be touching the RenderRequest at all, I believe this has to do only with the Request of the servlet, not the RenderRequest of the portlet.

query string parameters must take precedence over existing render request parameters, at least for the scope of the JSP.

I read this as meaning:

1) the Request needs to contain the same set of parameters as the RenderRequest and also any parameters included as query strings in the path. There are two separate parameter lists.

2) the query string parameters need to take precedence in the Request parameter list. In this case, it means that if the query string contains the same parameter as one which was included in the RenderRequest, the query string value needs to take precedence (as in take precedence in the Request parameter list, not the RenderRequest parameter lists).

From the spec, I believe it should work as follows:

- RenderParameters: name1 = value1 name2=value2

- path for request dispatcher: /test.jsp?name1=value3

Then from the jsp:

request.getParameter("name1") -> value3

request.getParameter("name2") -> value2

renderRequest.getParameter("name1") -> value1

renderRequest.getParameter("name2") -> value2

[trong.tran]

From the spec, I believe it should work as follows:

- RenderParameters: name1 = value1 name2=value2

- path for request dispatcher: /test.jsp?name1=value3

Then from the jsp:

request.getParameter("name1") -> value3

request.getParameter("name2") -> value2

renderRequest.getParameter("name1") -> value1

renderRequest.getParameter("name2") -> value2

Yes, that is exactly what is expected from the spec i think

[rraposa]

Matt and Trong - thank you for the clarification! I appreciate your time.

So with the example being used here:

- RenderParameters: name1 = value1 name2=value2

- path for request dispatcher: /test.jsp?name1=value3

What do you think the output of the following should be in test.jsp:

${name1}

In other words, is the Expression Language a shortcut to the renderRequest parameters or the request parameters?

Thanks!

Rich

P.S.: By the way, the output of ${name1} will be value1.

[trong.tran]

Rich Raposa wrote:

Matt and Trong - thank you for the clarification! I appreciate your time.

So with the example being used here:

- RenderParameters: name1 = value1 name2=value2

- path for request dispatcher: /test.jsp?name1=value3

What do you think the output of the following should be in test.jsp:

${name1}

In other words, is the Expression Language a shortcut to the renderRequest parameters or the request parameters?

Thanks!

Rich

P.S.: By the way, the output of ${name1} will be value1.

I think it makes sense to returns the same value as request.getParameter("name1"), that is value3. Anyway it's just my opinion as these are not very clear in spec from my reading. Somebody who has good experienced view on this could tell something more persuasively