Bug 780054 - (SOA-2419) Drools called from an EJB do not see objects in working memory
Drools called from an EJB do not see objects in working memory
Product: JBoss Enterprise SOA Platform 5
Classification: JBoss
Component: JBossESB, JBoss Rules (Show other bugs)
Unspecified Unspecified
urgent Severity urgent
: ---
: 5.1.0 GA
Assigned To: Tihomir Surdilovic
: Regression
Depends On:
  Show dependency treegraph
Reported: 2010-10-13 12:21 EDT by Martin Vecera
Modified: 2011-02-17 04:38 EST (History)
0 users

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2011-02-17 04:38:52 EST
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
slsb_action.tar.gz (17.06 KB, application/x-gzip)
2010-10-13 12:22 EDT, Martin Vecera
no flags Details

External Trackers
Tracker ID Priority Status Summary Last Updated
JBoss Issue Tracker SOA-2419 None None None Never

  None (edit)
Description Martin Vecera 2010-10-13 12:21:46 EDT
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"                                                                                                                                                             
        System.out.println("Rules are evaluating");                                                                                                                            

If you configure a rule that grabs any Driver object like the following one, it is not evaluated:
rule "log"                                                                                                                                                                     
    dialect "mvel"                                                                                                                                                             
        p : Driver( )                                                                                                                                                             
        System.out.println("Rules are evaluating");                                                                                                                            

However, the session bean puts a real populated object into it.
Comment 1 Martin Vecera 2010-10-13 12:22:50 EDT
Attachment: Added: slsb_action.tar.gz
Comment 2 Kevin Conner 2010-10-19 06:30:18 EDT
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.
Comment 3 Tihomir Surdilovic 2010-10-19 10:18:45 EDT
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?

Comment 4 Kevin Conner 2010-10-19 10:30:29 EDT
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.
Comment 5 Tihomir Surdilovic 2010-10-20 13:01:16 EDT
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.

Comment 6 Tihomir Surdilovic 2010-10-20 19:14:35 EDT
Link: Added: This issue is a dependency of BRMS-404
Comment 7 Tihomir Surdilovic 2010-10-20 19:16:35 EDT
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
Comment 8 Laura Bailey 2010-12-16 19:41:26 EST
Writer: Added: Darrin
Comment 9 Laura Bailey 2010-12-16 19:47:55 EST
Release Notes Docs Status: Added: Not Yet Documented
Comment 11 Martin Vecera 2011-01-27 09:15:12 EST
Verified in 5.1.0 ER8
Comment 12 Dana Mison 2011-02-17 04:38:52 EST
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.

Note You need to log in before you can comment on or make changes to this bug.