It definitely looks like this problem has nothing to do with portlet bridge.
When debugging GenericFacesPortlet.doDispatch() method, our team has realized that RenderRequest provided by PortletContainerImpl.doRender() invocation has null parameters (our uri is like http://localhost/portal/portal/default/mypage?foo=bar).
Thus, it is absolutely not possible implementing, f.ex., user password restoring use-case (user receives "activation link" with generated hash code by email, clicks it and enters special portal page with "enter your new password" prompt) with JBoss Portal. Saying we are pretty surprised is like saying nothing at all. :-(
Then we were looking through JBoss Identity Portlet and found out that they are using some "URLCommand MBeans" there to handle these urls. They are OF COURSE proprietary, not documented, and I am NOT going to file jira issue regarding this because answer will be the same as we had here (https://jira.jboss.org/jira/browse/JBPORTAL-2056): "THIS IS A PRIVATE API".
Atm we are trying to provide some workaround with RedirectServlet (out of jboss portal) deployed together with our ear which will handle urls like:
then it will save all request parameters to http session and redirect to URL provided. This is ABSOLUTELY UGLY way of doing things, but we do not see any other possibilities to handle our problem.
I do not expect anyone will answer this, because posting to jboss forums is always public speaking to myself :(