I am having the same problem and was considering the same type of solution.
Can you share your code?
I've searched high and low for info on this issue. I'm surprised it hasn't been encountered more....
Here is a link to my workaround:
I would still like to see other solutions. For example, plugging in a different FacesContextFactory impl.
Sorry I didn't get back to you in time. My solution is a bit simpler than yours since my wrapper doesn't act as a FacesContext since I figured that no one else would query the FacesContext from this particular attribute. But of course your solution is much better.
I am no a bid further since I now want my MyFaces app to be really clustered. I think that my sessions are replicated but when I switch from one cluster instance to another I get a ClassCastException (http://jira.jboss.com/jira/browse/JBPORTAL-1094). Right now it looks as if I have troubles with the fact that my two cluster portal instances share the same database since the my Portlet apperantly doesn't initialize on the portal that is the last one to start (I get error from portlet registry saying that the portlet app is already registered).
Have you succeded in getting a MyFaces based portlet running in a cluster (and be really clustered)?
I think you are a head of me. I have done the following:
- installed jboss-portal-ha.sar in an all server
- using a single mysql db for jbossportal
- validated that the out of the box portlets like weather "appear" to be clustered
then tried my jsf seam portlets and got the error discussed in this thread.
now i have no errors, but i got dragged off in another direction for a while.
so i can't say it is really clustered yet.
i believe you are supposed to have only one shared database for the portal cluster. maybe the if-exists tags in the *-object.xml descriptors play a role here....
i'll post any progress i make.
I was doing some other developing for some time but now found the time to go further with the clustering. I got it working and have some comments:
One has to distinquish between traditional JSF-apps and JBoss SEAM apps clustering is different depending on the platform used. JBoss SEAM keeps the stateful managed beans in the EJB3 layer which must be some thing the JSF will consider later since it makes good sense: it is a better strategy to keep stateful session data in a stateful ejb since then the app server can do what it is best at at the appropriate "level".
BUT since my app is a traditional JSF app I could figure (from the JBoss Portal docs) that I would have to "touch" my managed beans in the session whenever I changed their state. This has some implications since this is against what was intended in JSF.
If one bean has relations with another this relationship would normally be managed in the faces-config.xml (by injection) but this would never call set attribute on the portlet session when one changes the state on the
And if a page needs info from a managed bean in the session the JSF-framwork will generate a new empty bean and place it in the session for the page to use. This first bean creation will call setAttribute a cause session replication whereas other state changes only will appear as mutator calls on the bean in mention.
I know that JBoss tomcat replication now has the POJO replication but don't really know how this relates to the JBoss Portal session listener.
My solution is to have a bean handler that will fetch beans from the session and that will release these again by calling set attribute on the portlet session for the bean that had a state change. Much like the session interceptor used by JBoss Portal. And this worked. So know I have portlet implemented using traditional MyFaces that really is clustered.
I still use my custom MyFaces generic portlet but the other issue I mentioned above (http://jira.jboss.com/jira/browse/JBPORTAL-1094) wasn't really an error in the JBoss Portal (sorry about that Julien Viet) merely code that at first sight looked a bit suspecious.