13 Replies Latest reply on Oct 26, 2006 6:36 PM by brittm

    status of merge, non persisted script on fork, and n-out-of-

    Ronald van Kuijk Master


      There is a scenario within our company where we need the multiple choice (WFP06) and multi merge (WFP08) patterns.

      When I deploy a process with a merge node in it, I get the following exception:

      org.hibernate.HibernateException: instance not of expected entity type: org.jbpm.graph.node.Merge is not a: org.jbpm.graph.def.Node

      When looking at the code, I see that it does extend org.jbpm.graph.def.Node, it is in node.types.xml, but is not referenced in comments in Node.hbm.xml nor does it have its own hibernate mapping file. The code also states that an explicit merge is not needed since in jBPM multiple transitions can go into a node. This would do for a non-synchronizing merge, correct? A synchronizing merge would be a normal join then, correct? Shouldn't we either remove the merge node completely (it is not visible in the gpd either) or fully support it?

      Regarding the accompanying multi choice, In the pattern testcases this is done by a script on a fork (which is sufficient for us). However, this script is not persisted as is shown in the logging, and therefor the multi-choice will not work in real life without a custom fork (to bad since it is a common pattern in our branche). Is there a reason for the script not to be persisted? Is it easily changed? Again, I'd say fully support it or drop support. Or should we introduce conditions on transitions as an alternative (or support both)?

      A generic mechanism of conditions on transitions would also make guarded transitions possible or better prevent certain transitions from showing up in the ui, the only difference is the moment of evaluation.

      The last item regarding nodes is the n-out-of-m join. It is possible to do this programatically, but wouldn't it be better to have support for this in the schema as well? Just like with the previous node issues, I'd say we should support it or drop support and show an alternative.

      I won't file jira issues for this yet, since I want to discuss it first.