[rules-dev] Possible bug in looping ruleflows

[Michael Neale]

sounds like a bug. Please do JIRA this, with a test case if you can. I think
its settled down a bit, so we should be able to fix things like this now.

Thanks for looking into it.

Michael.

On 5/21/07, Shahad Ahmed <shahad.ahmed2 at gmail.com> wrote:
>
> I've been trying out the latest version of the ruleflow and I think I may
> have found a bug when creating looping ruleflows. I think the bug is in
> RuleFlowProcessInstance.getNodeInstance, where I suspect there is a return
> in the wrong place in the if-then-else that deals with ISplit node.
> I created a looping ruleflow that contains a Join and  Split node, where the
> Split decides if we should enter the loop and the Join allows a flow to
> re-enter the loop body. The issues is that the second time the same Split
> node is re-entered I always get the following exception:
>
>  java.lang.IllegalArgumentException: Illegal node type: class
> org.drools.ruleflow.core.impl.Split
>  at
> org.drools.ruleflow.instance.impl.RuleFlowProcessInstance.getNodeInstance(
> RuleFlowProcessInstance.java:121)
>  at
> org.drools.ruleflow.instance.impl.RuleFlowSequenceNodeInstance.triggerCompleted
> (RuleFlowSequenceNodeInstance.java:38)
>  at org.drools.common.RuleFlowGroupImpl$DeactivateCallback.execute(
> RuleFlowGroupImpl.java:191)
>  at org.drools.common.AbstractWorkingMemory.executeQueuedActions(
> AbstractWorkingMemory.java:992)
>  at org.drools.common.AbstractWorkingMemory.fireAllRules(
> AbstractWorkingMemory.java:375)
>  at org.drools.common.AbstractWorkingMemory.fireAllRules (
> AbstractWorkingMemory.java:353)
>  at org.drools.examples.SequentialTest.runTest4(SequentialTest.java:192)
>  at org.drools.examples.SequentialTest.main(SequentialTest.java:27)
>
> This exception is only thrown if the ruleflow contains an unknown node,
> but org.drools.ruleflow.core.impl.Split is a valid node (i.e. an instance
> of ISplit)! Looking at the body of RuleFlowProcessInstance.getNodeInstance  I think the return in the following part of the if-then-else is in the
> wrong place:
>
> else if ( node instanceof ISplit ) {
>             IRuleFlowNodeInstance result = getFirstNodeInstance(
> node.getId() );
>             if ( result == null ) {
>                 result = new RuleFlowSplitInstance();
>                 result.setNodeId( node.getId() );
>                 addNodeInstance( result );
>                 return result;
>             }
> }...
>
> This code would mean that the second time the Split is entered, result is
> not null, so "if ( result == null )" is never entered, which results in
> dropping out of the if-then-else and activating the error exception above. I
> suspect the return should be outside the "if ( result == null )"
> if-statement just like the IJoin part of the if-then-else to give the
> following (correct?) code:
>
> else if ( node instanceof ISplit ) {
>             IRuleFlowNodeInstance result = getFirstNodeInstance(
> node.getId() );
>             if ( result == null ) {
>                 result = new RuleFlowSplitInstance();
>                 result.setNodeId( node.getId() );
>                 addNodeInstance( result );
>             }
>           return result;
> }...
>
> Once I changed the return, looping seemed to work fine. I wasn't sure
> about raising a JIRA about this, as this stuff is still under development.
>
> Regards
> Shahad
>
>
> _______________________________________________
> rules-dev mailing list
> rules-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/rules-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/rules-dev/attachments/20070528/07d519c3/attachment.html