And now I realize name was poor, and should now be ‘userTaskAssignValidationHandler’
However, this will break previously running processes, as they won’t find old delegate bean (taskAssignValidatorHandler).
I would assume the same anytime we rename / refactor other bean references such as:
#{myObject.myMethod()}
What are best practices for this kind of refactoring / change isolation?
One idea I had was we could use version # in process name, such as ApprovalProcess_v1.0.bpmn, ApprovalProcess_v2.0, etc - only when there would be breaking changes for running processes. However, this means I would lose history across those process renames.
I don’t know what the best practices are since I don’t have much experience and also not have a rich statistics, but the question is a very interesting one.
The problem is that you have to have the process model (containing the bean refs) and the backing code (providing the beans) in synch. I’d address the problem by using the containers (docker or the like). This way you’d have your application completely packaged. Even if different containers whould use the same process DB, this would still work because each container would produce a new version of the process model. Instances of different versions (of the same process model key and version tag) still “know” to which version the belong, so there shold not be any problems here.
If you do not use containers (but rather e.g. a web app within a server) then it could get hard to separate the code for the different versions of the process model.