These are the files that I've altered:

FacesContextFactoryImp
SwfLifecycleExecutor
MainPortlet
Constants

and then an example of the portlet.xml file (with an added parameter to get the flow id)

As you can see, I died in the attempt of describing the changes I've made

So instead I've attached the altered files. The changes are wrapped in these comments:

//peb patch start
...changes
//peb patch end

Hopefully you'll be able to decipher my changes, othervise, please do not hesitate to contact me. Hope this is of any use to you.

Create post on your forum:

http://www.icefaces.org/JForum/posts/list/9891.page

I've tried to patch ICEfaces 1.7.2 too....And hazzah, it is working, meaning that we're now running ICEfaces 1.7.2 and Spring Web Flow 2.0.3 together on a WebSphere Portal Server 6.0 (and WebSphere Application Server 6.0 for that matter).

I've included the changed (and new) files in the attached zip file.

MainPortlet, FacesContextFactoryImpl and Constants are patched the same way as the ones I patched for version 1.7.1. The SwfLifecycleExecutor however, took some more work. The reason being that some code where introduced in the SwfLifecycleExecutor class to handle the result of executing a Spring Web Flow. This new code was quite servlet orientated with a lot of HttpPServletRequests and HttpServletResponses flying through the air.

Therefore I made a new interface called FlowExecutionHandler, with a method called handleFlowExecutionResult(). This method then takes care of handling the Spring Web Flow execution result. Furthermore I created two new classes, called ServletFlowExecutionHandler and PortletFlowExecutionHandler which both implements the FlowExecutionHandler interface. Most of the "new" (introduced in 1.7.2) code in SwfLifecycleExecutor, used for handling the SWF result, was then moved to the ServletFlowExecutionHandler class. The PortletFlowExecutionHandler does not do an awfull lot at the moment. Mainly because, to be quite honest, I don't know exactly what it is supposed to do. Help on this will be most appreciated

Next up, I created a FlowExecutionHandlerFactory which, given an external context of type org.springframework.webflow.context.ExternalContext, returns the correct FlowExecutionHandler (Servlet or Portlet). This factory is then used in SwfLifecycleExecutor to retrieve the correct FlowExecutionHandler, which is then used to handle the flow execution result.

Finally, I cleaned up the code in SwfLifecycleExecutor a bit, as the apply() method had grown quite long after my fiddlin' around.

Maybe this solution is over engineered, but feel free to use which parts of it you want. And as I said, any help (or just hints) on the PortletFlowExecutionHandler is very welcome.

I've just taken the liberty of creating the same issue, but as a bug instead of an improvement, hoping that this will help speeding up the process

It would be helpful if you could determine if this issue is still present/relevant in ICEfaces 1.8. If so, we could review an updated patch for 1.8 / latest icefaces/trunk.

the issue still exists in ICEfaces 1.8. I'm almost done patching the code here, and will submit a patch to you soon (just need to clean up and comment )

Finally! Here's the patch, sorry it took so long. Hope this is of any usage to you

This patch looks good and the changes appear to be confined to Portlet/SWF integration. The only concerns would be:

• ensure that no runtime dependency on portal.jar is introduced
• com/icesoft/jasper/Constants.java appears to be used for more than constants relating to the Jasper compiler (however, this use is not specific to this patch, so there is "precedent").

I've merged the changes into the latest code. Just checking to see if we have any regressions in the booking application.

I've checked in this code after running the booking app successfully. There still needs to be some major Spring Portal testing.

Peter,

This has been committed, please verify using WebSphere Portal, etc.

I've downloaded and build ICEfaces 1.8.2-RC1 and it appears to be in order. Great!