JBossDeveloper

Then this is not allowed. It breaks the principle of separation between portlets.

Another portlet on the same page shouldn't be affected by the url parameters targeted to another portlet.

The long term solution is to use public render parameters as we've done for regular webapps in 2.7.

JSR-301 still has to define its relation with Portlet 2.0 spec.

Anyway, Wesley is the Portlet bridge boss, it's up to him to decide if he wants to include the hack.

Really strange. Our task, I suppose, is pretty common to any web application (either portal or servlet based) - like sending user to password restoration page or users exchanging direct links to specific photo gallery or whatever.
For instance, if we have this forum running within the portal page, how do I send anyone the link to this conversation?
It looks like http://www.jboss.com/index.html?module=bb&op=viewtopic&t=139184, so how could ForumPortlet access these "module", "op" and "t" parameters in its RenderRequest?

I've seen the "portlet targeted urls" term mentioned in the Portlet Spec, but did not find anywhere how to use it with JBoss Portal (tried to find it in Portlet Spec, Jboss Portal documentation, JBoss Wiki, Google - no success).

If there are any possibilites to use more portlet-specific URLs like http://localhost/portal/portal/default/restore/RestorePortlet?user=10000&code=fh4ufh92yf97ty9f, this will be absolutely suitable for us.

http://localhost/portal/portal/default/restore/RestorePortlet?user=10000&code=fh4ufh92yf97ty9f

would work

nope :(
it does not.

http://localhost:8080/portal/portal/default/restore/EvaUserRestorePasswordPortlet?user=10000&code=fh4ufh92yf97ty9f

(PortletRequest) FacesContext .getCurrentInstance().getExternalContext().getRequest().getRequestParameterMap() is null

http://localhost:8080/portal/portal/default/restore/EvaUserRestorePasswordPortletInstance?user=10000&code=fh4ufh92yf97ty9f

(PortletRequest) FacesContext .getCurrentInstance().getExternalContext().getRequest().getRequestParameterMap() is still null

portlet.xml looks like this:

...
 <portlet>
 <description>EvaUser Restore Password Portlet</description>
 <portlet-name>EvaUserRestorePasswordPortlet
 </portlet-name>
 <display-name>Eva User Restore password Portlet</display-name>
 <portlet-class>ru.eva.core.web.EvaFacesPortlet
 </portlet-class>
 <init-param>
 <name>javax.portlet.faces.defaultViewId.view
 </name>
 <value>/jsf/restore-password.xhtml</value>
 </init-param>
 <init-param>
 <name>default-view</name>
 <value>/jsf/restore-password.xhtml</value>
 </init-param>
 <supports>
 <mime-type>text/html</mime-type>
 <portlet-mode>VIEW</portlet-mode>
 </supports>
 <portlet-info>
 <title>Eva User Restore Password Portlet</title>
 <keywords>user,request password</keywords>
 </portlet-info>
 <expiration-cache>-0</expiration-cache>
 </portlet>
...

 <deployment>
 <instance>
 <display-name xml:lang="en">Eva User Restore password Portlet</display-name>
 <instance-id>EvaUserRestorePasswordPortletInstance</instance-id>
 <portlet-ref>EvaUserRestorePasswordPortlet</portlet-ref>
 </instance>
 </deployment>

Ok, I've just checked this to be sure:)

public class EvaFacesPortlet extends GenericFacesPortlet {
 @Override
 public Boolean getPreserveActionParameters() {
 return true;
 }
}

I would need to have a deep look at it, but i don't have the time at the moment. An action URL should work though.

ok, I'll file a JIRA bug regarding this, so you'll be able to get back to it when you'll have time

"wesleyhales" wrote:

Try adding to your portlet.xml:

<init-param>
 <param-name>javax.portlet.faces.preserveActionParams</param-name>
 <param-value>true</param-value>
 <init-param>

"wesleyhales" wrote:
Thomas is right, you should generate an actionURL for this.

Portlet API have a special method in the RenderResponse interface : createRenderURL. From JSR-168 PLT 7.1 :

A render URL is an optimization for a special type of action URLs. The portal/portlet-
container must not invoke the processAction method of the targeted portlet.xxvi The
portal/portlet-container must ensure that all the parameters set when constructing the
render URL become render parameters of the subsequent render requests for the
portlet
Render URLs should not be used for tasks that are not idempotent from the portlet
perspective. Error conditions, cache expirations and changes of external data may affect
the content generated by a portlet as result of a request triggered by a render URL.
Render URLs should not be used within forms as the portal/portlet-container may ignore
25 form parameters.
Portlets can add application specific parameters to the PortletURL objects using the
setParameter and setParameters methods. A call to any of the setParameter
methods must replace any parameter with the same name previously set.xxviii All the
parameters a portlet adds to a PortletURL object must be made available to the portlet as
request parameters.xxix Portlet developers should note that the parameters of the current
30
render request are not carried over when creating a PortletURL.