How to change default ConflictResolver - drools

Question

As stated in title I'd like to change conflict resolver in my Drools project. I found following snippet on this site
ConflictResolver[] conflictResolvers =
new ConflictResolver[] { SalienceConflictResolver.getInstance( ),
FifoConflictResolver.getInstance( ) };
RuleBase ruleBase = java.io.RuleBaseLoader( url, CompositeConflitResolver( conflictResolver));
However it lacks of information where to put it and what sholud be url parameter.
Thank you in advance for any help.

Answer 1

As the documentation says:
Drools 4.0 supported custom conflict resolution strategies; while this
capability still exists in Drools it has not yet been exposed to the
end user via knowledge-api in Drools 5.0.
http://docs.jboss.org/drools/release/5.2.0.Final/drools-expert-docs/html/ch04.html
So if you are using Drools 5+ you will not be able to change conflict resolver unless you do some reflection magic. The Conflict Resolver is settled inside the Agenda object of the StatefulKnowledgeSession object. You can see this by using debugger (it's the content of Agenda object):
To replace ConflictResolver, first you need instance of StatefulKnowledgeSession (which will be ksession in the following snippet). Then you need to extract some nested private fields and after that you can replace field value with instance of i.e RandomConflictResolver. Full code:
Agenda agenda = ksession.getAgenda();
Field agendaField = agenda.getClass().getDeclaredField("agenda");
agendaField.setAccessible(true);
Object agendaObject = agendaField.get(agenda);
Field mainField = agendaObject.getClass().getDeclaredField("main");
mainField.setAccessible(true);
Object mainObject = mainField.get(agendaObject);
Field queueField = mainObject.getClass().getDeclaredField("queue");
queueField.setAccessible(true);
Object queueObject = queueField.get(mainObject);
Field comparatorField = queueObject.getClass().getDeclaredField("comparator");
comparatorField.setAccessible(true);
Object comparator = comparatorField.get(queueObject);
ConflictResolver randomResolver = org.drools.conflict.RandomConflictResolver.getInstance();
comparatorField.set(queueObject, randomResolver);
Based on : documentation and debugger session.

Answer 2

To demonstrate that the order of firings does not affect the overall outcome I'd use an AgendaFilter. I'm sketching the outline using 6.x, but this API hasn't changed since 5.x.
KieBase kieBase = ...;
Collection<KiePackage> packages = kieBase.getKiePackages();
List<Rule> rules = new ArrayList<>();
for( KiePackage p: packages ){
rules.addAll( p.getRules() );
}
Now you have all the rules. Build this simple filter that accepts a single rule:
class Selector implements AgendaFilter {
List<Rule> rules;
int ruleIndex;
Selector( List<Rule> rules ){
this.rules = rules;
}
void setRuleIndex( int value ){ this.ruleIndex = value; }
int getRulesSize(){ return rules.size(); }
boolean accept(Match match){
return match.getRule().equals( rules.get( ruleIndex ) );
}
}
Instantiate:
Selector selector = newSelector( rules );
You can now execute all rules that are activated (but see below):
for( int i = 0; i < selector.getRulesSize(); ++i ){
int fired = kieSession.fireAllRules( selector, i );
}
Any other permutation of 0..size-1 may produce another sequence of firings. You may do this systematically for a small number of rules, or you may use some random permutations.
A more efficient test would keep track of the Match data passed to the filter in the first run and use only these for successive executions.
Caution The approach outlined so far does not consider changes in Working Memory. It would be possibe for rule n to become activated when some rule n+k is fired. If you do have changes of Working Memory, you will have to
do {
int sumf = 0;
for( int i : somePermutation ){
int fired = kieSession.fireAllRules( selector, i );
sumf += fired;
}
} while( sumf > 0 );
I have never done a test like this. It seems that getting the correct result by depending on the innate order of rule firings is extremely rare, in contrast to getting all sorts of wrong results from this order.
Note Other permutations of the rule firing order are possible by changing the order of rules in the DRL (or in their packages?) or by changing the order of fact insertions into working memory. For certain scenarios, even this may provide enough test cases for showing what you intend.