yes.. you are missing that if you don't put the agenda group in the stack it will never be used. Like Bali said "Whenever the focus is set to a different group, Drools adds this group to a stack". If you don't set the focus to another agenda group, the only one in the Stack is MAIN. On Thu, Jan 21, 2010 at 1:11 PM, Pritam <infinity2heaven(a)gmail.com&gt; wrote: -- - http://salaboy.wordpress.com - http://www.jbug.com.ar - Salatino "Salaboy" Mauricio -

LOL, by "jeopardize the intention of the developer" you mean "guess what the developer wanted to do but didn't know how to model" or more like "teach the developer how to use a stack"? :) Seriously, there is a reason why stacks work like they do and why agenda-groups are handled as stacks. You can try to use ruleflow-groups instead of agenda-groups, if you want to coordinate your rules in a more straight forward (I guess we could say more natural, sequential) way. Although, even with ruleflow-groups, you need to model them in the correct order or things will not go as you would like them to. Edson 2010/1/21 Pritam <infinity2heaven(a)gmail.com&gt; -- Edson Tirelli JBoss Drools Core Development JBoss by Red Hat @ www.jboss.com

Hehe, ok, lets try to clarify then. In your example, you have 2 rules. Assuming your are *not* using any kind of grouping, when you insert the message with status HELLO, then engine knows that only the first rule is eligible to execute, and so the engine fires it. The consequence of rule 1 changes the message status, making rule 2 eligible and so it fires in sequence. That is called rule chaining, and that is how forward chaining engines like drools work and do inference. So, in that simplistic example, if you go simple (as in not using groups), the engine is smart enough to figure out what to do. Now, real use cases can be modeled like that and implemented using a few tricks like control facts and it will work. Although, that would miss the point of being a declarative platform for behavior modeling. So, Drools introduced a few ways to coordinate the execution of rule groups, namely agenda-groups, ruleflow-groups and activation-groups. Whenever you *explicitly* set one of these attributes in the rule, you are telling the engine: "- I know what I am doing. Do as you are told and don't try to be smart." That is why, the setFocus() methods define the order in which elements are placed into the stack and it will execute them in the given FIFO (stack semantic) order, or not execute them at all. So: * agenda-groups: uses stack semantics, as you quoted in your first e-mail. The stack starts with the MAIN agenda-group, and every time you call setFocus() from the application code *or* from a rules consequence *or* a rule with auto-focus true is activated, it will push that group on top of the stack. This is extremely useful for cases like exception handling (not *java* exception, more like "exceptional cases") among other situations. It can also emulate "sub-procedure" semantics, where a given reasoning cycle is paused while another reasoning cycle is called and when that finishes, it comes back to he original reasoning cycle and continues. * ruleflow-group: uses workflow semantics, where you define a sequential flow/process and each step is executed in sequence. This is a much easier way to model sequencing, and specially useful for process-like or phased execution. The modeling is also visual, making it easier for users to deal with. * activation-group: it tells the engine that the rules in that group are mutually exclusive and whenever one of them fires, it automatically cancels the activations of all other rules in the same group. I personally don't like this one and always avoid it when authoring rules, but it is there for those that want to use the feature. Whenever you use any of these controls, you are telling the engine to comply with their semantics. That is why I thought your comment on "jeopardizing developer intentions" was funny, but I meant no disrespect. One thing is to admit you are not understanding something. I different thing is to criticize something you don't understand. I always tell users to start simple: try letting the engine figure out which rules to fire and which order. If that does not work for you, then look for alternatives. One can do extremely sophisticated models by mixing the above groups in the same rule, but you need to know what you are doing or things might not result in the way you expected them to be. Edson 2010/1/21 Pritam <infinity2heaven(a)gmail.com&gt;

I think you already figured out, but the stack starts only with the MAIN group and you must explicitly call setFocus in order to add a group to the stack. If a group is not added to the stack, the rule activation will remain in the group waiting to be placed in the stack. Edson 2010/1/21 Pritham <infinity2heaven(a)gmail.com&gt; -- Edson Tirelli JBoss Drools Core Development JBoss by Red Hat @ www.jboss.com

In the consequence of rule 1 you could write: drools.setFocus( "group 2" ); That will immediately place the group 2 on top of the stack and, since the rule 2 will be active, it will fire rule 2 in the sequence. Another way is, in rule 2, add the attribute: auto-focus. Whenever that rule is activated, the engine places it's group (in your example, group 2) on top of the stack, also allowing the rule to fire. Please note that for the simple example being discussed, all 3 approaches have the same effect, but for real life examples with hundreds or thousands of rules, sometimes it will be easier to use auto-focus, some times it will be easier to use drools.setFocus(). []s Edson 2010/1/22 Pritham <infinity2heaven(a)gmail.com&gt; -- Edson Tirelli JBoss Drools Core Development JBoss by Red Hat @ www.jboss.com