Parameter passing and forwarding issues with 10.1.4 JSR 168 portlets

Question

Hi,
I'm using version 10.1.4 version of Oracle Portal Server, and am trying to move a JSP web application to a JSR 168 compliant portlet.
I am experiencing these issues:
1. There are <form> tags in my JSPs. I've set the action attribute to "<portlet:actionURL>". This works okay and I can see the parameters in my processAction properly. However, if I modify the action attribute to "<portlet:renderURL>", I do not see any parameters in my doView(). Is this expected or a known bug?
2. As a workaround of the issue #1, in my processAction, I'm using response.setRenderParameter(). This works but has a serious side effect: the first set of values set are set permanently for the session. Subsequent submissions of my JSP fail to alter the values. Is this expected? This problem is not there if setRenderParameter() is not used.
3. My JSPs use request.setAttribute() and request.getSession().setAttribute(). I don't see these attributes in my processAction using request.getAttributeNames(). Is there another way of retrieving them?
4. In my JSP, I have this code in a method declaration:
String forwardPage = "hello.jsp";
RequestDispatcher forwarder = request.getSession().getServletContext().getRequestDispatcher(forwardPage);
forwarder.forward(request, response);
This results in an exception on the server:
     06/05/07 00:25:10 AnupamPortlets: JspServlet: unable to dispatch to requested page: java.lang.NullPointerException
     at com.evermind.server.http.HttpApplication.isLegalFileSystemPath(HttpApplication.java:1298)
     at oracle.jsp.runtimev2.JspServlet.internalService(JspServlet.java:502)
     at oracle.jsp.runtimev2.JspServlet.service(JspServlet.java:413)
     at javax.servlet.http.HttpServlet.service(HttpServlet.java:853)
     at com.evermind.server.http.ServletRequestDispatcher.invoke(ServletRequestDispatcher.java:824)
     at com.evermind.server.http.ServletRequestDispatcher.forwardInternal(ServletRequestDispatcher.java:330)
     at com.evermind.server.http.ServletRequestDispatcher.forward(ServletRequestDispatcher.java:253)
     at opportunity_detail____contacts__view._Controller.processRequest(_Controller.java:2516)
     at opportunity_detail____contacts__view._Controller._jspService(_Controller.java:2592)
     at com.orionserver.http.OrionHttpJspPage.service(OrionHttpJspPage.java:56)
     at oracle.jsp.runtimev2.JspPageTable.service(JspPageTable.java:350)
     at oracle.jsp.runtimev2.JspServlet.internalService(JspServlet.java:509)
     at oracle.jsp.runtimev2.JspServlet.service(JspServlet.java:413)
     at javax.servlet.http.HttpServlet.service(HttpServlet.java:853)
     at com.evermind.server.http.ServletRequestDispatcher.invoke(ServletRequestDispatcher.java:824)
     at com.evermind.server.http.ServletRequestDispatcher.include(ServletRequestDispatcher.java:121)
     at oracle.webdb.wsrp.server.RequestDispatcherImpl.include(Unknown Source)
     at mypackage1.Portlet1.doView(Portlet1.java:158)
I've tried moving the page around and using request.getContextPath() and getNamedDispatcher(), but same error.
This is supported, right? I saw some old messages about this being a bug on the PDK side.
Actually, using forwarder.include() works, but causes other issues
Any ideas what I can try of any of these will be greatly appreciated. Thanks.

Answer 1

Hi Anupam,
I can help you with question #2.
2. As a workaround of the issue #1, in my processAction, I'm using response.setRenderParameter(). This works but has a serious side effect: the first set of values set are set permanently for the session. Subsequent submissions of my JSP fail to alter the values. Is this expected? This problem is not there if setRenderParameter() is not used.
I believe that the issue is an artifact of the interpretation of the JSR-168 specification by Oracle. I discovered that the setRenderParameter basically ends up sending a redirect back to the browser with the render parameters in the URL. This raised security concerns as you may have wanted to pass some sort of internal data from your action to your render request. The parameters in the url "hang around" once they are there so your portlet keeps recieving them. Based on this behavior I have decided to not use setRenderParameter in Oracle portal.
-sean
Solutions Architect
www.sagelogix.com