I can't think of a better long weekend !<br><br>2 bugs !<br><br><div><span class="gmail_quote">On 4/8/07, <b class="gmail_sendername">Mark Proctor</b> <<a href="mailto:mproctor@codehaus.org">mproctor@codehaus.org</a>
> wrote:</span><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">Found two great bugs this weekend:<br><br><a href="http://jira.jboss.com/jira/browse/JBRULES-778">
http://jira.jboss.com/jira/browse/JBRULES-778</a> (fixed)<br>when<br> $p : Person( $cheese : cheese )<br>then<br> modify( $cheese )<br>end<br>The above would actually use the $p fact handle for the modify, causing<br>
the handle to reference $cheese instead of $p. This is now fixed, field<br>bindings now have their fact hand cleared, so on modify when the fact<br>handle is null it retrieves it from the working memory.<br><br><a href="http://jira.jboss.com/jira/browse/JBRULES-780">
http://jira.jboss.com/jira/browse/JBRULES-780</a> (in the process of fixing)<br>no-loop is currently trapped with:<br> // if the current Rule is no-loop and the origin rule is the<br>same then return<br> if (
this.rule.getNoLoop() && this.rule.equals(<br>context.getRuleOrigin() ) ) {<br> return;<br> }<br><br>That means we have a tuple that reached the terminal node, but is not<br>added to the memory or an activation created and attached. Thus on a
<br>modify or a retract the Tuple reaches the RuleTerminalNode and causes a<br>NullPointer.<br>_______________________________________________<br>rules-dev mailing list<br><a href="mailto:rules-dev@lists.jboss.org">rules-dev@lists.jboss.org
</a><br><a href="https://lists.jboss.org/mailman/listinfo/rules-dev">https://lists.jboss.org/mailman/listinfo/rules-dev</a><br></blockquote></div><br>