Currently Spring Web Flow "fits" into the JSF lifecycle via a FlowPhaseListener. This is a simple integration approach, however it has several disadavantages:
- All of the code related to flow execution lifecycle management is JSF specific, and duplicated with the FlowExecutor which processes requests in the other supported environments. Special constructs like a FlowCleanupFilter must be maintained because of limitations in the JSF lifecycle.
- Exceptions that occur outside the Flow Execution cannot be handled by the FlowExecution. For example, consider an exception that occurs when a UIComponent renders. Such an exception is impossible to handle by the Flow. Special-case JSF extensions must be written to deal with these exceptions.
- Issuing cleanup callbacks like session.disconnect() after view rendering is hard to do, and adapter (e.g. JSF) specfiic
- Supporting JSF in a Portlet environment is harder, and results in further portlet-specific integration code
- In general, SWF has less control over things, making it harder to fully utilize its power.
This issue should investigate putting Web Flow itself in full control of driving the JSF component lifecycle. This will allow for high-level JSF + SWF integration code to be eliminated, and for common request dispatching and flow execution lifecycle management code to be reused consistently across all integration environments.
This enhancement most likely depends on enhancements to the core engine to complete. Specifically, a view selection rendering phase most likely will needed to be added to the SWF lifecycle. Also, this enhancement would benefit from several core engine enhancements. Specifically, the ability to fork off flow executions asynchronously from within a view state (called flow composition).