0

I am new to drools and have defined two rules :

package com.mgaudin.sandbox.drools.rules;

import com.mgaudin.sandbox.drools.models.Lead;

rule "rule1"
    when
        l: Object()
    then
        System.out.println(l.getClass().getCanonicalName());
end

And

package com.mgaudin.sandbox.drools.rules;

import com.mgaudin.sandbox.drools.models.Lead;

rule "rule2"
    when
        Lead()
    then
        System.out.println("It's a match !");
end

When I insert a new com.mgaudin.sandbox.drools.models.Lead fact, the output is the following :

com.mgaudin.sandbox.drools.models.Lead

Therefore we can deduce that :

  1. The rules compiles properly
  2. The rules are executed
  3. The first rule matches with a fact of type "com.mgaudin.sandbox.drools.models.Lead"

So why is the rule "rule2" not matching ?

Thanks !

VitalyZ
  • 445
  • 1
  • 4
  • 12
Maxime
  • 1,776
  • 1
  • 16
  • 29
  • 1
    Does it signify something that you appear to have two .DRL files? Are both compiled into a single KieBase? How? Have you verified that there are two rules in it? – laune Jun 20 '17 at 10:36
  • Both are compiled into the same KieBase (the first rule was there just to prove that my drools was running properly and display the fact class name). I tried compiling my rule either using the KieFileSystem / KieBuilder or using a KnowledgeBuilder. Both compiled fine but produced the same result. Also, to be sure that my DRL file was used, I tried modifing the same file with eval(true) which outputs "It's a match !". – Maxime Jun 20 '17 at 12:06
  • 1
    If there are no hidden snags in your story then I'd say that this is a bug. Make a complete example (minimum Java, DRL), state the Drools version and raise a JIRA. - If you edit your question, adding all of this code & info, I'd look into it. – laune Jun 21 '17 at 08:26

3 Answers3

4

OK I found the answer and it's not related to Drools, it's related to Spring-boot-devtools !

I don't know the exact mechanism but to enable fast hot reload (even if a method signature changes), spring-boot-devtools must mess with the JVM and proxify some objects, in my case, the fact. Because of this and the way Drools matches fact, the rule did not triggered.

All I had to do was remove the maven dependency to spring-boot-devtools.

Maxime
  • 1,776
  • 1
  • 16
  • 29
  • 1
    I can confirm that I had the same issue with these same tools and removing spring-boot-devtools fixed the problem. – Renato Dinhani Dec 06 '17 at 05:23
  • Was facing the same issue and fixed by removing `spring-boot-devtools` – Mahadeva Jan 13 '19 at 19:50
  • for us the issue occurred when we are trying to read this rules as kjar from spring boot application. Able to figure out that we should maintain the same package structure in order to get the facts loaded and recognized properly in rules when condition. – Jajikanth pydimarla Apr 28 '21 at 18:57
1

Rules are not matching since your fact (Lead) is loaded with different ClassLoader so Drools don't see it. This is done by devtools as described here: https://docs.spring.io/spring-boot/docs/current/reference/html/using-boot-devtools.html#using-spring-boot-restart-vs-reload

But it's not necessary to disable devtools, just add the following lines to META-INF/spring-devtools.properties as was hinted here:
restart.include.drools=/drools-[\\s\\S]+\.jar restart.include.kie=/kie-[\\s\\S]+\.jar So Drools is loaded with Restart Classloader - the same as your Classes.

VitalyZ
  • 445
  • 1
  • 4
  • 12
  • This will only keep drools and kie jars in RestartClassLoader but not your facts and custom classes. It's not guaranteed using this will fix the problem. – Mahadeva Jan 13 '19 at 19:51
0

I had a problem that inserted facts are never recognized inside rules, but had no problem with globals.

Removing

spring-boot-devtools

dependency made my life easier.

Janko Ljubić
  • 1
  • 1