i just finished generalization of the conditions (SEAM request). previously, it was only
possible to specify conditions on transitions leaving a decision node.
now, (from 3.2.Alpha3 and onwards) it will be possible to specify conditions on any
transition. these will be checked at runtime.
also i added the functionality to the token of getting all the transitions for which there
is no condition or a condition that resolves to true. this method is called
by implementing this in a backwards compatible way, i realized that the current behaviour
is still very awkward. a decision will scan and evaluate all transitions that have a
condition first. the first transition for which its condition resolves to true will be
taken. if no transition with a condition resolves to true, the default (=the first one)
will be taken.
with pain in my heart :-( i saw that the docs actually explained different behaviour then
what is implemented. so i had to update the docs explain the less intuitive behaviour...
snif. A decision will take the first transition that has no condition or that has a
condition which resolves to true.
i have kept this strange behaviour for backwards compatibility reasons. As far as i can
see now, old processes with decision conditions will still work in the new version. Also
if you redeploy processes with decision conditions, they will still work (i have marked
the expression attribute on the condition as deprecated). The new versions will never use
the JBPM_DECISIONCONDITION table any more. But i left it in the hibernate mappings so
that there is no need for a conversion script. If people don't have old deployments
with decision conditions, they can just remove that table.
DO YOU THINK THAT IS A WISE 'DECISION' ? Or should i just change the decision
behaviour to the more intuitive and backwards incompatible mode ?
View the original post :
Reply to the post :