<br>&nbsp;&nbsp;&nbsp; Hi,<br><br>&nbsp;&nbsp;&nbsp; Really interesting project. Congratulations!<br>&nbsp;&nbsp;&nbsp; Regarding your question, I just plugged the DebugAgendaEventListener to the manners test working memory, and it seems to be working fine. This default implementation of agenda event listener simply prints out the events. See bellow a snippet of the log generated by it:
<br><br>[BeforeActivationFired: rule=makePath; tuple=[fid:2187:2555:[Path id=63, seat=63, guest=2]]<br>[fid:2250:2624:[Seating id=64 , pid=63 , pathDone=false , leftSeat=63, leftGuestName=2, rightSeat=64, rightGuestName=1]]
<br>[fid:169:2628:[Context state=MAKE_PATH]]<br>]<br>[AfterActivationFired(2691): rule=makePath]<br>[BeforeActivationFired: rule=pathDone; tuple=[fid:2250:2624:[Seating id=64 , pid=63 , pathDone=false , leftSeat=63, leftGuestName=2, rightSeat=64, rightGuestName=1]]
<br>[fid:169:2628:[Context state=MAKE_PATH]]<br>]<br>==&gt;[ActivationCreated(2757): rule=areWeDone; tuple=[fid:2250:2692:[Seating id=64 , pid=63 , pathDone=true , leftSeat=63, leftGuestName=2, rightSeat=64, rightGuestName=1]]
<br>[fid:168:168:[LastSeat seat=64]]<br>[fid:169:2693:[Context state=CHECK_DONE]]<br>]<br>==&gt;[ActivationCreated(2757): rule=continue; tuple=[fid:169:2693:[Context state=CHECK_DONE]]<br>]<br>[AfterActivationFired(2691): rule=pathDone]
<br>[BeforeActivationFired: rule=areWeDone; tuple=[fid:2250:2692:[Seating id=64 , pid=63 , pathDone=true , leftSeat=63, leftGuestName=2, rightSeat=64, rightGuestName=1]]<br>[fid:168:168:[LastSeat seat=64]]<br>[fid:169:2693:[Context state=CHECK_DONE]]
<br>]<br>&lt;==[ActivationCancelled(2757): rule=continue; tuple=[fid:169:2693:[Context state=PRINT_RESULTS]]<br>]<br>==&gt;[ActivationCreated(2758): rule=allDone; tuple=[fid:169:2694:[Context state=PRINT_RESULTS]]<br>]<br>
[AfterActivationFired(2757): rule=areWeDone]<br>[BeforeActivationFired: rule=allDone; tuple=[fid:169:2694:[Context state=PRINT_RESULTS]]<br>]<br>[AfterActivationFired(2758): rule=allDone]<br><br>&nbsp;&nbsp;&nbsp; As you can see, seems all events are correctly reported. I&#39;m using trunk (
4.0.1.SNAPSHOT), but I am not aware of any problem in 4.0GA either. <br>&nbsp;&nbsp;&nbsp; Just as a test, try plugging it in your system and check the results... i you still think it is a problem, can you please open a JIRA and attach a self contained test case showing the problem? 
<br><br>&nbsp;&nbsp;&nbsp; []s<br>&nbsp;&nbsp;&nbsp; Edson<br>&nbsp;&nbsp;&nbsp; <br>&nbsp;&nbsp; <br><br><div><span class="gmail_quote">2007/8/30, 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>Hi!<br><br>I&#39;m using a JTable to display rules that have been activated.<br><br>My goal is to have the table display a set of activations ordered by their<br>salience. The user should then choose which one of them to fire (if you want
<br>to know why, be invited to read the background).<br><br>Of course this makes only sense as long as the activations are valid. Rules<br>whose activation has been cancelled should still be displayed, but in a<br>different style (like greyed out).
<br><br>In order to accomplish this, I want to use an implementation of the<br>AgendaEventListener-interface, implementing the<br>activationCancelled()-method.<br>The Listener itself works, as I use the activationCreated()-method to add
<br>the rule as a row to my table (which works fine).<br><br>Unfortunately the activationCancelled()-method doesn&#39;t seem to be executed<br>at all!<br><br><br>I assume that I have a fundamental misunderstanding of what should trigger
<br>an activationCancelled() event?<br><br><br>Background: (just if you&#39;re curious...)<br>I&#39;m working as a PhD student in physics at the CERN international<br>high-energy physics laboratory, for the ATLAS experiment.
<br>As a member of the Detector Control System (DCS) group, I&#39;m going to write<br>an expert system in order to assist the shift crew with the detector<br>operation.<br><br>The operation of the detector is a difficult task, because more than 70000
<br>parameters (like voltages, currents and temperatures) have to be controlled.<br>A Finite State Machine (FSM) computes a defined and limited number of states<br>from the given parameters (like ON, OFF, STANDBY,...).<br>
<br>I&#39;m going to synchronize the expert system application to ERROR states of<br>the FSM, in order to extract the relevant parameters from the system (as it<br>would be impossible to feed all parameters into the XPS all the time).
<br>This is handled by quite some control rules that decide which data has to be<br>requested, released and so on.<br>Once all necessary data has been received, this might lead to activations of<br>the (more interesting) user rules.
<br>Those rules have an explanatory character like &quot;The temperature of this XYZ<br>is too high, so please try ABC.&quot;<br><br>For a given set of facts I assume more then one rule to be activated. Whilst<br>the rule engine should take care of the execution (firing) of all control
<br>related rules, the execution of the user rules should be under direct user<br>control.<br><br>Displaying all activations in a GUI will allow the user to pick one (try it)<br>and rate it (the proposed solution solved the problem &quot;yes/no&quot;). Changing
<br>the rules salience according to the answer, will allow the system to<br>dynamically reflect the current system status. (Rules that are related to<br>broken connections / wrongly connected cables are likely to be found at the
<br>beginning of the experiment but hopefully only on rare occasion later on.)<br><br>In order to ensure that no information is lost during the absence of DCS<br>experts (which will not always be around), a log file should be written for
<br>each major FSM-ERROR. At the moment the WorkingMemoryFileLogger seems to be<br>predestined for this job. This way I hope to collect large amounts of ERROR<br>data during the initial phase of the experiment that helps to extract rules
<br>for numerous error conditions.<br>This will become especially handy, as such errors have a tendency to come<br>back, even if the original detector experts are gone for years...<br>--<br>View this message in context: <a href="http://www.nabble.com/activationCancelled%28%29-not-being-executed--tf4348054.html#a12387991">
http://www.nabble.com/activationCancelled%28%29-not-being-executed--tf4348054.html#a12387991</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>