Thanks Wesley. I already have this on my portlet.xml. I have excluded the config from the faces-config (I was really confused by that :) )

But still I can't access the parameters:

PortletRequest request = (PortletRequest)this.facesContext.getExternalContext().getRequest();
String x = request.getParameter("foo");

Actually, the parameters are null, no matter the query string on the browser window.

Could you please advice?

Regards

I'm still stucked with this :(

No matter which impl (B1,B2,B3) It is not possible to access request parameters from the PortletRequest inside my ManagedBean.

Reading the javadoc for the API:

# javax.portlet.faces.preserveActionParams: specifies on a per portlet basis whether the bridge should preserve parameters received in an action request and restore them for use during subsequent renders.

Well tried to re-implement the javax.faces.GenericPortlet and I can not find the parameter (passed on the request uri) in none of the methods (render, doView)

Tried the constructor of my bean... nothing. It seems that the bridge is not passing away the parameters from the uri.

This is the only parameter avaible at those locations:

Parameters[javax.faces.portletbridge.STATE_ID=uploadB2Portlet24DFF11F65E83699968F1D8DED7297ACview87b1e5d1-07b3-407d-89ea-aa935ae79ac6]

No other is visible.

Any ideas?

Well the only way we found to access the request:

JBossRenderRequest request = (JBossRenderRequest)facesContext.getExternalContext().getRequest();
 HttpServletRequest originalReq = null;
Field f = request.getClass().getSuperClass().getSuperClass().getDeclaredField("dreq");
f.setAccessible(true);
originalReq = (HttpServletRequest)f.get(request);

Guys,

Any advance with this problem? We understand that you are pretty busy with all portletbridge stuff, so could you please provide at least some hints on this, we'll be glad to fix/extend the GenericFacesPortlet (or whatever) and contribute our patches.

Well, when having a 3 members in a team, problems sometimes is being solved pretty fast.

What we've done is a hack around JBoss proprietary ControllerContext class (will definitely NOT work in liferay or whatever). It just copies everything from original ClientRequest request parameters to RenderRequest request attributes with "x-url-param." prefix. This is done due to the fact that PortletRequest.getRequestParameterMap() returns an immutable instance (which is definitely sane behavior).

Ok, our code follows, we are looking forward to have it in the next Portlet Bridge beta :)
Should we file a JIRA issue with this code attached?

package ru.eva.core.web;

import java.io.IOException;
import java.util.Map;

import javax.portlet.PortletException;
import javax.portlet.RenderRequest;
import javax.portlet.RenderResponse;
import javax.portlet.faces.GenericFacesPortlet;
import javax.servlet.http.HttpServletRequest;

import org.apache.commons.beanutils.PropertyUtils;

public class EvaFacesPortlet extends GenericFacesPortlet {

 @Override
 protected void doDispatch(RenderRequest request, RenderResponse response)
 throws PortletException, IOException {
 try {
 HttpServletRequest clientRequest = (HttpServletRequest) PropertyUtils
 .getNestedProperty(request,
 "controllerContext.serverInvocation.serverContext.clientRequest");
 if (clientRequest != null
 && clientRequest.getParameterMap() != null) {
 for (Map.Entry e : request.getParameterMap().entrySet()) {
 request.setAttribute("x-url-param." + (String) e.getKey(), e.getValue());
 }
 }
 } catch (Exception ex) {
 // client request is not available here :(
 }

 super.doDispatch(request, response);

 }

}

What is not working with the ControllerContext in LIferay ?

Oh sorry i misunderstood.

Any chances this will be in the next PortletBridge so we'll get rid of this extra code in our own project? ;-)

Any chances this will be in the next PortletBridge so we'll get rid of this extra code in our own project? ;-)

We need a generic solution.

Thomas,

Following to the Portlet Spec (PLT.11.1.1 Request Parameter s), this is absolutely up to portlet-container implementation, so I am afraid that there are no generic solutions possible (rather than configurable JBossPortalRequestParameterHandler, LiferayPortalRequestParameterHandler, WhateverElseRequestParameterHandler approach):

PLT.11.1.1 Request Parameter s

The portlet-container must not propagate parameters received in an action request to
subsequent render requests of the portlet.l If a portlet wants to do that, it can use render
URLs or it must use the setRenderParameter or setRenderParameters methods of
the ActionResponse object within the processAction call.

How are you trying to pass the parameters ?

Thomas,

In any possible way. Our task is to send user the "restore your password link" via e-mail so he's able to click it and access "password restoration" portal page with "restore user's password" portlet. The link we are sending should contain userId and some generated hash code so we could recognize user and allow him to change the password.

At the moment, the link sent is:
http://localhost:8080/portal/portal/default/restore?user=9094750&code=ba55b37e4a7c4357667a5a77521c2580

With our EvaFacesPortlet code provided above, we are doing this in our Seam Managed Bean:

@Name("userRequestManager")
@Scope(ScopeType.EVENT)
public class UserRequestManager {

 private User restoringUser;
 private boolean findUserRequestAttempted; //do not attempt to find user multiple times in the same request

 ...

 public User getRestoringUser() {
 if (restoringUser == null && !findUserRequestAttempted) {
 PortletRequest req = (PortletRequest) FacesContext
 .getCurrentInstance().getExternalContext().getRequest();
 Long userId = NumberUtils.toLong((String) req
 .getAttribute("x-url-param.user"));
 String hash = (String) req.getAttribute("x-url-param.code");
 User user = us.findUserById(userId);
 if (hash != null && hash.equals(user.getRegistrationHash())) {
 this.restoringUser = user;
 }
 this.findUserRequestAttempted = true;
 }
 return restoringUser;
 }
...
}