The format of URLs has been improved toward that direction in 2.4.
The format or an action or render URL is like /portal/portal/default/mypage/mywindow?a=b&c=d&...
Where /portal/portal is a prefix that depends on your settings, /default/mypage/mywindow is the path to the portlet window targetted by the request and the list of parameters contains either render parameters or action parameters.
A special parameter is also inserted in the list of parameters in order to make the portal distinguish between action and render.
We also can render page using an URL that points to a page. However any parameter to a page is discarded and never propagated to any portlet.
Yes, we ended up doing something like:
* Introduce a command servlet
* Rewrite rules changing the "nice" url to one with parameters that the servlet can parse (including which portal page to use)
* Do checking and logic in the command servlet
* Use HTTP getting directly inside the command servlet to the correct render url, targetting ctrl:page=Portal.Page with additional parameters
* Introduce a portlet superclass that uses Policy to obtain the actual servlet request, and put that on the session so that each portlet on that page can access the information
Not the best of solutions, but no JBoss-specific classes used, and objective reached.
I am thinking of another way, that does not deal do much with servlet and deep mechanism.
if I understand well your will, you want to get some parameters before the rendering process has started, and share them with all the portlets.
For "intercepting" these parameters, you can build your own CommandFactories, derived from the one provided with jbp.
They filters the parameters that you want to share and send them, through a message store, to all the portlets that will need it.
as a message store and sharing parameter implementation, you can use the M. Osmond implementation.
see this post : http://jboss.org/index.html?module=bb&op=viewtopic&t=87442
(this feature of sharing parameters seems also to be in preparation for JSR-168 2.0 and in jbp 2.4 with the access to the portal objects nodes).
The thing is to use the messaging implementation from inside a command factory, to send messages from there instead of from the portlets.
The message must be stored with a reference to a "Session ID".
In a Portlet, it uses the PortletSessionID to send the message.
In the CommandFactory, the message may be sent in the same way, but with providing the session id (coming from the httpSessionId).
There's some work to do to adapt the messaging class, so it can do a send, with other parameters than the PortletRequest.
In the commandFactory, it seem you can retrieve the SessionID from the Invocation => Request => HttpRequest (to check really, I have just had a quick look at it).
To check : the portlet session Id must be the same as the http session id (which should be, but I am not sure the JSR ask for this... and quite sure not...)
To put your command factories in place of the one provided by jbp, you can use the service methods to unregister the ones and register yours in place off, or, more simple, replace the jboss-service.xml with yours, that say to use your classes instead of the one defined.
a lot of work, but it seems ok to work.
I would set first the Messaging Portlet implementation, and check that the session identification for messages can be the same from the one that you get from the command factory, so you can send the message from there.
then see the command factory side.
after, it should be easy. lot of setting, testing and tuning.
the advantage is not to deal with servlet stuff that much, but more "after", when the portal processes the request".
and by using the Messaging implementation, you can use it for other needs. It provide by itself a good way to manage this sharing of parameters issue, and good ideas on how to do it (multiple same portlet on one page, etc...).
hope it may help.