<br>&nbsp;&nbsp; It is really difficult to answer that since your understanding seems correct. Is it possible for you to provide a self contained test showing the problem?<br><br>&nbsp;&nbsp; []s<br>&nbsp;&nbsp; Edson<br><br><div><span class="gmail_quote">
2007/10/11, Fermion &lt;<a href="mailto:henss@physik.uni-wuppertal.de">henss@physik.uni-wuppertal.de</a>&gt;:</span><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<br>It&#39;s been a while since I had time to investigate this problem.<br><br>I followed your advice and hooked up the DebugAgendaEventListener to my<br>workingMemory instance.<br><br>This clearly shows, that my activations are created but never canceled. So
<br>at least it is consistent with what I&#39;m observing in my application.<br><br>But before I start even considering it being a bug (I&#39;m quite sure it is<br>not), maybe it&#39;s better to understand what is happening in my code:
<br><br>I think that I nailed my problem down to an issue with my fact IDs:<br><br>If I have, for example, a real world value (lets say a temperature) that is<br>connected to a java bean, my understanding is, that the fact ID of this
<br>value inside the workingMemory should not change, even if I change the real<br>world value (temperature rises)(and thus the java beans value).<br>In fact the change is propagated to the working memory (as I call<br>&quot;firePropertyChange&quot; inside my bean), but a NEW rule is activated by the
<br>changed fact, having a DIFFERENT fact ID!<br><br>I&#39;m quite sure that this is the reason for my problem with the missing<br>cancellations. I&#39;d assume that for a rule to be canceled the fact with the<br>CORRECT fact ID would have to be changed.
<br><br>Now, in my application, it seems that every modification creates a NEW fact<br>inside the working memory (which is of course not, what I want).<br><br>I had the hope, that calling the firePropertyChange from inside the beans
<br>&quot;setters&quot; would notify the working memory automatically about the correct<br>fact-ID.<br><br>I checked my &quot;equals()&quot; and &quot;hashCode()&quot; methods but the hash code is always<br>constant and equals is correspondingly true. I also checked that I don&#39;t
<br>accidentally re-assert the fact on modification.<br><br>So what I don&#39;t understand is WHY the working memory thinks that the fact ID<br>has changed...<br><br>See you,<br><br>fermion<br>--<br>View this message in context: 
<a href="http://www.nabble.com/activationCancelled%28%29-not-being-executed--tf4348054.html#a13158335">http://www.nabble.com/activationCancelled%28%29-not-being-executed--tf4348054.html#a13158335</a><br>Sent from the drools - user mailing list archive at 
<a href="http://Nabble.com">Nabble.com</a>.<br><br>_______________________________________________<br>rules-users mailing list<br><a href="mailto:rules-users@lists.jboss.org">rules-users@lists.jboss.org</a><br><a href="https://lists.jboss.org/mailman/listinfo/rules-users">
https://lists.jboss.org/mailman/listinfo/rules-users</a><br></blockquote></div><br><br clear="all"><br>-- <br>&nbsp;&nbsp;Edson Tirelli<br>&nbsp;&nbsp;Software Engineer - JBoss Rules Core Developer<br>&nbsp;&nbsp;Office: +55 11 3529-6000<br>&nbsp;&nbsp;Mobile: +55 11 9287-5646
<br>&nbsp;&nbsp;JBoss, a division of Red Hat @ <a href="http://www.jboss.com">www.jboss.com</a>