Bug 724459 (BRMS-404)

Summary: Drools called from an EJB do not see objects in working memory
Product: [JBoss] JBoss Enterprise BRMS Platform 5 Reporter: Tihomir Surdilovic <tsurdilo>
Component: BRE (Expert, Fusion)Assignee: Tihomir Surdilovic <tsurdilo>
Status: CLOSED NEXTRELEASE QA Contact:
Severity: unspecified Docs Contact:
Priority: high    
Version: 5.1.0.ER1   
Target Milestone: ---   
Target Release: 5.1.0 GA   
Hardware: Unspecified   
OS: Unspecified   
URL: http://jira.jboss.org/jira/browse/BRMS-404
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2010-10-20 23:18:09 UTC Type: Feature Request
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:

Description Tihomir Surdilovic 2010-10-20 23:14:17 UTC
securitylevel_name: Public

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.

Comment 1 Tihomir Surdilovic 2010-10-20 23:14:35 UTC
Link: Added: This issue depends SOA-2419


Comment 2 Tihomir Surdilovic 2010-10-20 23:18:09 UTC
Changed the CL order. Now consecutive test runs also show:

2010-10-20 19:09:29,174 INFO  [STDOUT] (pool-34-thread-1) Driver's computed risk group=10

Comment 3 David Le Sage 2010-10-25 23:43:15 UTC
Draft release notes text states:


https://jira.jboss.org/browse/BRMS-404

 If an ESB application had a custom action that called an EJB session bean that used JBoss Rules to evaluate an incoming object, JBoss Rules was not able to see that object.  This occurred because the classes were loaded via the jbrules.esb class loader rather than the context class loader and the class was cached between deployments, meaning the class loader was leaked.  To fix this problem, the order has been changed so that the context class loader is activated before the current one.  As a result, the rules now find the class loader that they are expecting to see.

Comment 4 Dana Mison 2010-10-26 06:55:50 UTC
Writer: Added: dlesage


Comment 5 Dana Mison 2010-10-26 07:10:35 UTC
Release Notes Docs Status: Added: Documented as Resolved Issue


Comment 6 Dana Mison 2010-10-27 03:05:52 UTC
Release Notes Text: Added: test


Comment 7 Dana Mison 2010-10-27 03:13:13 UTC
Release Notes Text: Removed: test 


Comment 8 David Le Sage 2010-11-15 07:02:36 UTC
Release Notes Text: Added: If an ESB application had a custom action that called an EJB session bean that used JBoss Rules to evaluate an incoming object, JBoss Rules was not able to see that object.  This occurred because the classes were loaded via the jbrules.esb class loader rather than the context class loader and the class was cached between deployments, meaning the class loader was leaked.  To fix this problem, the order has been changed so that the context class loader is activated before the current one.  As a result, the rules now find the class loader that they are expecting to see.