The current execution engine implementation is composed of 3 very tightly coupled classes: FlowExecutionImpl, FlowSessionImpl and RequestControlContextImpl. The FlowSessionImpl is a package private helper class used internally by the FlowSessionImpl as its FlowSession implementation – no problem there. Things get a bit stranger when you look at the relationship between FlowExecutionImpl and RequestControlContextImpl.
Conceptually, the RequestControlContext implementation serves as a facade used by flow definition artifacts (States, Actions, ...) to interact with and manipulate the ongong flow execution in the context of the current request. However, if you look at the FlowExecutionImpl, e.g. the start() method, you see that it sets up a RequestControlContextImpl (which is normal), and than uses that context to call back into itself...weird. Another strange thing is that responsability of notifying FlowExecutionListeners is shared between the FlowExecutionImpl and RequestControlContextImpl. Sometimes listeners are notified by the FlowExecutionImpl, sometimes by the RequestControlContextImpl – that's obviously not ideal.
The current implementation works fine but should be revised to be easier to understand.