Enhance XML-defined action chains to support equivalent CompositeAction functionality [SWF-42]

[spring-operator]

Alex Antonov opened SWF-42 and commented

Right now when I specify the <entry> or <exit> behaviors during the state definition, they would execute an action, but regardless of its status continue on the execution of the state. When looking at the implementation, such a state gets an Entry/ExitAction set as a CompositeAction which takes inside the newly created AnnotatedAction object which is indeed being called to execute whatever it is you've specified.

Looking at the CompositeAction i see a property which indicates if it should stopOnError. But there is no way to indicate if the newly created CompositeAction object that wraps my entry/exit behaviors should stop if the <entry> action returns an error Event in response.

Could the change be made to the XmlFlowBuilder to accept a property element that would allow us to specify if we want an <entry> stopOnError and what that errorEventId should be instead of just doing a state.setEntryAction(new CompositeAction(parseAnnotatedActions(entryElement ))); call.

A proposed implementation would be to allow those two attributes to be part of the <entry>/<exit> tags i.e. <entry stopOnError="true" errorEventId="failure">...</entry> This way with very little overhead parcing during the building of the flow, we would allow this behavior to be controllable within the xml, thus reducing the need for in-code flow implementations. Also, due to the fact that you can not create a spring bean for the entry action and bind it via <entry bean="blah">...</entry> call, it makes it impossible to create a work around by defining a custom action class to handle such a behavior.

---

Affects: 1.0.4

Issue Links:

• #206 Transition actions should optionally allow continuing running other actions after an action failure

[spring-operator]

Erwin Vervaet commented

So far our advice for situations where you want control over how the flow reacts to action execution results has been to put the action(s) in a seperate action state and wire your flow such that it passes through this action state whenever required.

Still, your suggestion seems reasonable and only affects the builder, so no problem there.