I haven't had the opportunity to test this, but I imagine anyone with a pretty good understanding of how conversations are implemented could answer, so I pose it here first...
In developing a BEA Portal application for a client, I've come across this idea of a "refreshAction" for a portlet - specifically it refers to a Java Page Flow action (old BEA/now Apache Beehive Pageflow, and possibly could be a Struts action I suppose) that gets called when a page that contains the portlet in question is refreshed. The problem comes down to when you have a JPF, which is somewhat analogous to a Conversation (except it's seemingly a single object stored under an "active pageflow" key in the HttpSession I believe), if you have it wrapped in a portlet and refresh the page containing your JPF portlet your Pageflow state is lost. Presumably it's due to the fact that the portal doesn't know the state of your portlet and by default it won't re-execute the processAction step of the portlet lifecycle. So the portal assumes the portlet is in the proper state and just does the render phase for the portlet, which makes any state lower than session scope disappear. I haven't tried this with a JSF portlet, but am wondering if the way Seam has implemented conversations totally averts the problem... Sorry for over-explaining the issue - this has all been a long winded way of asking, are conversations stored in a map structure under the Session? If so - when wrapping a Seam app in a portlet, has this problem been addressed? In particular, it has to do with the portal framework thinking that the portlet is in a processAction state prematurely. BEA's solution for this is to set a property on the portlet called "refreshAction" that will get called in this scenario - if the page is refreshed your you switch to another page can come back. The right way to solve it would be to have the Pageflow state available and restore it. In the context of a Seam app, this would be having the current long running conversation stored along with the rest of the portlet state, and put into the Portal's context before re-rendering the portlet. As an aside, I haven't looked at JBoss Portal, but I imagine that they take an approach that isn't as asinine as BEA's to solve this problem. :-) Portals would make much more sense if only WSRP were really feasible. FYI - I'm desperately pushing the need for JavaEE 5 (and Seam) adoption mainly on the simple fact that completely counter-intuitive hacks like this pervade any new Java web development that doesn't adopt it (ahem... SPRING... and WLP 10...) Any input on this is appreciated - sorry if I didn't do a good job of explaining the problem. Have a look at the following link if you can bare a little more info: http://forums.bea.com/thread.jspa?threadID=200019490 View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4084713#4084713 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4084713 _______________________________________________ jboss-user mailing list [email protected] https://lists.jboss.org/mailman/listinfo/jboss-user
