Portal 2.4 + JSF + IPC Navigation not properly navigating

[emdlc]

As in the IPC example in the documentation, I have a portletA, the source portlet window, and portletB, the destination portlet window.

My current setup has one portlet-shared code-base that deploys into one zipped SAR file. The two portlets using IPC are defined together in one portlet.xml file, one portlet-instances.xml file, one *-object.xml file, one web.xml and one faces-config.xml. The inner-class listener in my portlet class that extends MyFacesGenericPortlet, is a copy of the IPC example (except for the portlet window names and debugging logs). That extension is used for portletB's <portlet-class>. The MyFacesGenericPortlet is used for portletA. The test I use is a <h:commandLink> with a literal value action attribute:

<h:commandLink action="navigateOtherWindow">
 <f:verbatim>Test</f:verbatim>
</h:commandLink>

Instead of changing portletB's window to the <to-view-id> of 'navigateOtherWindow', it changes it to the <from-view-id> location.


With or without a <from-view-id> element:

<navigation-rule>
 <navigation-case>
 <from-outcome>navigateOtherWindow</from-outcome>
 <to-view-id>/jsp/dest.jsp</to-view-id>
 </navigation-case>
</navigation-rule>

or

<navigation-rule>
 <from-view-id>/jsp/source.jsp</from-view-id>
 <navigation-case>
 <from-outcome>navigateOtherWindow</from-outcome>
 <to-view-id>/jsp/dest.jsp</to-view-id>
 </navigation-case>
</navigation-rule>

...when 'Test' is clicked from portletA, it changes portletB to '/jsp/source.jsp' instead of '/jsp/dest.jsp'.

With the listener off, the link works properly, but remaining in portletA's window.

Have any clues? Do I need to make a change to the listener? It seems to me that the setting of all of the source portlet's parameters as the parameters of the portletB's newEvent should do it.

[emdlc]

It seems that I had to change the web.xml to declare the elements necessary to a MyFaces webapp. I think the examples don't require them because they have them declared elsewhere in JBoss Portal? But for some reason it started navigating properly between portlets when I used this:

<?xml version="1.0" encoding="UTF-8"?>

<web-app id="web-app_1" xmlns="http://java.sun.com/xml/ns/j2ee"
 xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
 xsi:schemaLocation="http://java.sun.com/xml/ns/j2ee http://java.sun.com/xml/ns/j2ee/web-app_2_4.xsd"
 version="2.4">

 <context-param>
 <param-name>javax.faces.STATE_SAVING_METHOD</param-name>
 <param-value>client</param-value>
 </context-param>

 <context-param>
 <param-name>javax.faces.application.CONFIG_FILES</param-name>
 <param-value>/WEB-INF/faces-config.xml</param-value>
 </context-param>

 <listener>
 <listener-class>
 org.apache.myfaces.webapp.StartupServletContextListener
 </listener-class>
 </listener>

 <!-- Faces Servlet -->
 <servlet>
 <servlet-name>Faces Servlet</servlet-name>
 <servlet-class>javax.faces.webapp.FacesServlet</servlet-class>
 <load-on-startup>1</load-on-startup>
 </servlet>

 <!-- Faces Servlet Mapping -->
 <servlet-mapping>
 <servlet-name>Faces Servlet</servlet-name>
 <url-pattern>*.faces</url-pattern>
 </servlet-mapping>

</web-app>

Maybe it is the STATE_SAVING_METHOD being set to client? The way I'm seeing this is that even though it is deployed as one SAR, each portlet is deployed as a separate application. So when I set it to client, MyFaces embeds the appropriate values in the page itself, instead of server-side, so the destination portlet gets page parameters that help it navigate opposed to request attributes, which it cannot see since they are different apps?

But this doesn't seem to handle the case when you need to pass parameters, or ideally, managed-beans across. I can't even get regular parameters to go across (or at least how to access them). Any ideas?

Navigation still doesn't work when it references something from a managed bean, for example, I get this in the log if I click on it:

link:
 <h:form>
 <h:commandLink action="addItem">
 <f:param name="mainPortlet" value="true" />
 <f:param name="urlVal" value="#{item.url}" />
 <f:verbatim>Add</f:verbatim>
 </h:commandLink>
 </h:form>

log:
10:15:33,218 INFO [[/query-portlet]] WARNING: Component jbpa61aafa8_id26 just got an automatic id, because there was no id assigned yet. If this component was created dynamically (i.e. not by a JSP tag) you should assign it an explicit static id or assign it the id you get from the createUniqueId from the current UIViewRoot component right after creation!

...and the navigation goes to the from-view-id instead of the to-view-id. When looking this warning up, I get advice from non-portlet applications, to set the ID if you generate it using Java code. I imagine it reacts like this because the destination portlet is unaware of any JSF actions and managed beans that the source portlet has.

So my questions are:
- Do separate FacesContext objects exists for each portlet, or are they shared?
- If they are shared, can we have the portlets view the same managed-beans by setting id's?
- How do I pass and retrieve parameters from one portlet to another using JSTL and/or JSF tags?
- Are all these assumptions close to reality? Or am I way off?

[emdlc]

To clarify that last post, the 'mainPortlet' parameters is only used to inform the porlet listener on the main or destination portlet to do something with this request.

[frankr]

I'm also working on IPC using JSF and experience the same behavior as you mentioned: the target portlet shows the source view instead of the destination view. Changing the STATE SAVING to client makes it work in Fire Fox but then Internet Explorer 7 does not accept the URL anymore... When I click a link it does not display the page in IE.

Is there any way to make IPC JSF work without switching STATE SAVING to client?