Hi! I'm using a JTable to display rules that have been activated. My goal is to have the table display a set of activations ordered by their salience. The user should then choose which one of them to fire (if you want to know why, be invited to read the background). Of course this makes only sense as long as the activations are valid. Rules whose activation has been cancelled should still be displayed, but in a different style (like greyed out). In order to accomplish this, I want to use an implementation of the AgendaEventListener-interface, implementing the activationCancelled()-method. The Listener itself works, as I use the activationCreated()-method to add the rule as a row to my table (which works fine). Unfortunately the activationCancelled()-method doesn't seem to be executed at all! I assume that I have a fundamental misunderstanding of what should trigger an activationCancelled() event? Background: (just if you're curious...) I'm working as a PhD student in physics at the CERN international high-energy physics laboratory, for the ATLAS experiment. As a member of the Detector Control System (DCS) group, I'm going to write an expert system in order to assist the shift crew with the detector operation. The operation of the detector is a difficult task, because more than 70000 parameters (like voltages, currents and temperatures) have to be controlled. A Finite State Machine (FSM) computes a defined and limited number of states from the given parameters (like ON, OFF, STANDBY,...). I'm going to synchronize the expert system application to ERROR states of the FSM, in order to extract the relevant parameters from the system (as it would be impossible to feed all parameters into the XPS all the time). This is handled by quite some control rules that decide which data has to be requested, released and so on. Once all necessary data has been received, this might lead to activations of the (more interesting) user rules. Those rules have an explanatory character like "The temperature of this XYZ is too high, so please try ABC." For a given set of facts I assume more then one rule to be activated. Whilst the rule engine should take care of the execution (firing) of all control related rules, the execution of the user rules should be under direct user control. Displaying all activations in a GUI will allow the user to pick one (try it) and rate it (the proposed solution solved the problem "yes/no"). Changing the rules salience according to the answer, will allow the system to dynamically reflect the current system status. (Rules that are related to broken connections / wrongly connected cables are likely to be found at the beginning of the experiment but hopefully only on rare occasion later on.) In order to ensure that no information is lost during the absence of DCS experts (which will not always be around), a log file should be written for each major FSM-ERROR. At the moment the WorkingMemoryFileLogger seems to be predestined for this job. This way I hope to collect large amounts of ERROR data during the initial phase of the experiment that helps to extract rules for numerous error conditions. This will become especially handy, as such errors have a tendency to come back, even if the original detector experts are gone for years... -- View this message in context: http://www.nabble.com/activationCancelled%28%29-not-being-executed--tf434... Sent from the drools - user mailing list archive at Nabble.com. _______________________________________________ rules-users mailing list rules-users(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/rules-users

It's been a while since I had time to investigate this problem. I followed your advice and hooked up the DebugAgendaEventListener to my workingMemory instance. This clearly shows, that my activations are created but never canceled. So at least it is consistent with what I'm observing in my application. But before I start even considering it being a bug (I'm quite sure it is not), maybe it's better to understand what is happening in my code: I think that I nailed my problem down to an issue with my fact IDs: If I have, for example, a real world value (lets say a temperature) that is connected to a java bean, my understanding is, that the fact ID of this value inside the workingMemory should not change, even if I change the real world value (temperature rises)(and thus the java beans value). In fact the change is propagated to the working memory (as I call "firePropertyChange" inside my bean), but a NEW rule is activated by the changed fact, having a DIFFERENT fact ID! I'm quite sure that this is the reason for my problem with the missing cancellations. I'd assume that for a rule to be canceled the fact with the CORRECT fact ID would have to be changed. Now, in my application, it seems that every modification creates a NEW fact inside the working memory (which is of course not, what I want). I had the hope, that calling the firePropertyChange from inside the beans "setters" would notify the working memory automatically about the correct fact-ID. I checked my "equals()" and "hashCode()" methods but the hash code is always constant and equals is correspondingly true. I also checked that I don't accidentally re-assert the fact on modification. So what I don't understand is WHY the working memory thinks that the fact ID has changed... See you, fermion -- View this message in context: http://www.nabble.com/activationCancelled%28%29-not-being-executed--tf434... Sent from the drools - user mailing list archive at Nabble.com. _______________________________________________ rules-users mailing list rules-users(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/rules-users

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? []s Edson

After Edson helped me sort some things out, it came clear, that the actual problem is the use of agenda filters in my test. If one uses them, the "activation cancelled" events will not reach the listeners (I don't know whether the activations are cancelled or not). Disabling the agenda filters, the activation cancelled events will be propagated to the listeners. According to Edsons suggestion I filed a JIRA bug report that can be found at JBRULES-1775. I will try to avoid the problem by using agenda groups instead. After finding out, what caused the problem, it was possible to reduce the test code by quite a bit: http://www.nabble.com/file/p19598702/smaller_test.zip smaller_test.zip -- View this message in context: http://www.nabble.com/activationCancelled%28%29-not-being-executed--tp123... Sent from the drools - user mailing list archive at Nabble.com. _______________________________________________ rules-users mailing list rules-users(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/rules-users