Red Hat Bugzilla – Bug 780054
Drools called from an EJB do not see objects in working memory
Last modified: 2011-02-17 04:38:52 EST
project_key: SOA I have and ESB application that calls a custom action. In this custom action I call an EJB session bean. This bean uses Drools to evaluate the incoming object. See the attached application for more information. When I deploy the application (ant deploy) and run the test (ant runtest) it works well and you can see the following line in the console: 18:07:06,261 INFO [STDOUT] Driver's computed risk group=10 When you redeploy the application (ant undeploy, ant deploy) and run the test again, no rules except for a dummy log rule are evaluated. You can recognize it in the console log: 18:12:34,745 INFO [STDOUT] Driver's computed risk group=0 The rule file is jar/src/org/jboss/soa/esb/samples/quickstart/integration/drools/slsb/RiskGroup.drl. I believe that the issue is with working memory. Simple rule like the following gets evaluated: rule "log" dialect "mvel" when eval(true) then System.out.println("Rules are evaluating"); end If you configure a rule that grabs any Driver object like the following one, it is not evaluated: rule "log" dialect "mvel" when p : Driver( ) then System.out.println("Rules are evaluating"); end However, the session bean puts a real populated object into it.
Attachment: Added: slsb_action.tar.gz
This issue arises because the classes are loaded via the jbrules.esb classloader rather than the context classloader and the class is cached between deployments, leaking the classloader. Executing within the first deployment results in the session.insert using the expected class, thereby firing the rules. Subsequent deployments use the current class but this is not the version expected by the rules and so does not fire.
build.xml uploaded imports: <!-- Import the base Ant build script... --> <import file="../conf/base-build.xml"/> which is not available. This seems to be a case to use KnowledgeBuilderConfiguration and pass the classloaders needed to it, for example: KnowledgeBuilderConfiguration kbconfig = KnowledgeBuilderFactory.newKnowledgeBuilderConfiguration(null, classLoaders); KnowledgeBuilder kbuilder = KnowledgeBuilderFactory.newKnowledgeBuilder(kbconfig); ... would that help?
It is a quickstart and has to be exploded into the samples/quickstarts directory. The issue seems to be related to the default ordering of the classloaders rather than any explicit API invocation.
We will reverse the order (loading context cl before the "current" one) and run the drools tests. Btw. this test works fine on SOA-P 5.0.0. The order I believe was changed in Drools code for 5.1.
Link: Added: This issue is a dependency of BRMS-404
Switched the ordering and tested with ER2. Now consecutive test run also shows: 2010-10-20 19:09:29,174 INFO [STDOUT] (pool-34-thread-1) Driver's computed risk group=10
Writer: Added: Darrin
Release Notes Docs Status: Added: Not Yet Documented
Verified in 5.1.0 ER8
Release Notes Docs Status: Removed: Not Yet Documented Added: Documented as Resolved Issue Release Notes Text: Added: Using the JBoss Rules ESB service (jbrules.esb) from an EJB would not work for any EJB deployed after the first. This was because the classes were loaded using the jbrules.esb classloader instead of the context classloader. Because the class is cached between deployments, calls by subsequent deployments would be using the wrong classloader. This has been resolved by ensuring that all deployments would attempt to use the context class loader first.