Improve developer experience for conditional flows

[hpoettker]

Problem

The sample code in the reference documentation for conditional flows makes the critical assumption that stepA() is a proxied bean method. If the method were not proxied, its two invocations would return different instances where the DSL expects to be passed the same instance twice. But the assumption is not explicitly stated.

This leads to a lot of confusion and produces a number of user issues, for example #4429, #4328, #4348, and #4153.

Possible solutions

One possibility would be to adjust the documentation. Either by adding a warning to the section (which might confuse readers to whom the concept of proxied methods is unknown) and/or by changing the code snippet to inject the steps as parameters to the method.

Another possibility would be to change the implementation to be more lenient. There are already places in the code where unique names for a Step are assumed. Thus, AbstractStep could implement equals and hashCode base on the the step name, which should also fix the issue. If this path is chosen, it would make sense to address #3757 at the same time.

[fmbenhassine]

Thank you for raising this issue. We definitely need to update the docs to inject the steps as parameters of the job bean definition method. This injection style makes the dependencies of a bean clear from the signature of its definition method. This is the style that is used in recent additions/updates to the samples and getting started guide. We will also add a warning note about proxied vs non proxied methods for those who prefer using other dependency injection styles. I will plan this for 5.1.

Regarding step names, they should be unique within a flow definition. I don't see how we can detect that two steps are registered with the same name to correctly resolve #3757. I need to dig deeper to see what would be the best way to implement that (ideas are welcome). Adding name based equals and hashCode to AbstractStep makes sense as well, but probably won't change things much after this commit: edc197a. Probably that fix should be reviewed/reverted and fix the original issue in a another way (like detecting if the step is a proxy and get its name from the target object).

[hpoettker]

Thanks for the pointer to #857. It seems like the implementation could only depend on step names retrieved from a Step if more of the flow logic were deferred to the actual job execution. That makes things a bit more difficult.

[fmbenhassine]

The samples were updated and a warning was added at the top of the section: https://docs.spring.io/spring-batch/reference/step/controlling-flow.html. Hopefully this is better now.

The programmatic improvement will be addressed in #3757, see #3757 (comment).