4 Replies Latest reply on Aug 1, 2006 7:30 AM by Ronald van Kuijk

    Bugs in org.jbpm.graph.node.Decision?

    Jay Jay Newbie

      I was wondering why the following decision node doesn't work with v3.1.2:

      <decision name="d">
       <transition to="t1">
       <condition>#{myVar == 1}</condition>
       </transition>
       <transition to="t2">
       <condition)#{myVar == 2}</condition>
       </transition>
       <transition to='otherwise'/>
      </decision>
      

      When neither condition is true, the t1 transition is taken, not the 'otherwise' transition. When the second condition is true, transition t1 is taken.

      I believe there are a couple of flaws in Decision.java:

      1. A break probably is missing after line 121
      2. An assignment to transitionName is probably missing at line 126
      3. The calls to getDefaultLeavingTransition() at lines 126 and 140 are probably wrong, because the decision node type is document to take the last transition as the default transition, not the first one.

      Or am I missing something?

      Regards,

      Jay


        • 1. Re: Bugs in org.jbpm.graph.node.Decision?
          Ronald van Kuijk Master

          The working of decision has been the topic on this forum before e.g. http://www.jboss.com/index.html?module=bb&op=viewtopic&t=78714. Is the behaviour you see in line what is discussed there? Is that different from the docs (what version of the docs, the online ones or from the source) ?

          The reason I ask this is that it could be that the behaviour (how much it is unwanted) could be the 'correct/current' one.

          According to the online docs, a transition without a condition results to true (for the option to have the 'otherwise') It does not need to be the last one. The default transition is the first one.

          I'm not saying what you see is not a bug, but it is so fundamental and discussed before that I want to be sure.

          • 2. Re: Bugs in org.jbpm.graph.node.Decision?
            Jay Jay Newbie

            Ronald, thanks for responding. Regardless of whether the "otherwise" transition should be first or last (which is just a matter of convention), the current behavior is wrong. Here's a test case:

            package test;
            
            import junit.framework.TestCase;
            import org.jbpm.context.exe.ContextInstance;
            import org.jbpm.graph.def.ProcessDefinition;
            import org.jbpm.graph.exe.ProcessInstance;
            import org.jbpm.graph.exe.Token;
            
            
            public class TestDecision extends TestCase {
            
             public void testDecison0() {
             runProcess(0, "end");
             }
            
             public void testDecison1() {
             runProcess(1, "s1");
             }
            
             public void testDecison2() {
             runProcess(2, "s2");
             }
            
             private void runProcess(int value, String expectedState) {
            
             ProcessDefinition processDefinition = ProcessDefinition.parseXmlInputStream(getClass().getResourceAsStream("processdefinition.xml"));
             ProcessInstance processInstance = new ProcessInstance(processDefinition);
            
             ContextInstance contextInstance = processInstance.getContextInstance();
             contextInstance.setVariable("myVar", new Integer(value));
            
             Token token = processInstance.getRootToken();
            
             token.signal();
             assertSame(processDefinition.getNode(expectedState), token.getNode());
            
             }
            }
            


            With this processdefinition.xml:
            <process-definition name='Test Decision'
             xmlns='urn:jbpm.org:jpdl-3.1'
             xmlns:xsi='http://www.w3.org/2001/XMLSchema-instance'
             xsi:schemaLocation='urn:jbpm.org:jpdl-3.1 http://jbpm.org/jpdl-3.1.xsd'>
            
             <start-state>
             <transition to='d'/>
             </start-state>
            
             <decision name='d'>
             <transition to='s1'>
             <condition>#{myVar == 1}</condition>
             </transition>
             <transition to='s2'>
             <condition>#{myVar == 2}</condition>
             </transition>
             <transition to='end'/>
             </decision>
            
             <state name='s1'/>
            
             <state name='s2'/>
            
             <end-state name='end'/>
            
            </process-definition>
            


            testDecision0 and testDecision2 fail, the task being in the s1 state in both cases. When I put the otherwise transition at the first position, nothing changes.

            Note that if you replace the conditions with an expression, like this, all works fine:
             <decision name='d' expression='#{ myVar }'>
             <transition name='0' to='end'/>
             <transition name='1' to='s1'/>
             <transition name='2' to='s2'/>
             </decision>
            


            Regards,

            Jay


            • 3. Re: Bugs in org.jbpm.graph.node.Decision?
              Olivier Debels Newbie

              This is a nasty one.

              To keep it short: just add names to your transitions. The reason is that the Decision class is using these names to refer to the right transition. If the name is not filled in the default leaving transition will be taken.

              if (Boolean.TRUE.equals(result)) {
               transitionName = decisionCondition.getTransitionName();
               }
              


              I leave it up to you to decide if this is a bug (or by design) and should be filed in JIRA.

              Olivier.

              • 4. Re: Bugs in org.jbpm.graph.node.Decision?
                Ronald van Kuijk Master

                AAAAAAAAHHHHHHHHHHHHH SHOOT. you are right. Thanks a lot, this should be an explicitly documented thing....