Bug 780054 (SOA-2419) - Drools called from an EJB do not see objects in working memory
Summary: Drools called from an EJB do not see objects in working memory
Keywords:
Status: CLOSED NEXTRELEASE
Alias: SOA-2419
Product: JBoss Enterprise SOA Platform 5
Classification: JBoss
Component: JBossESB, JBoss Rules
Version: 5.1.0.ER2
Hardware: Unspecified
OS: Unspecified
urgent
urgent
Target Milestone: ---
: 5.1.0 GA
Assignee: Tihomir Surdilovic
QA Contact:
URL: http://jira.jboss.org/jira/browse/SOA...
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2010-10-13 16:21 UTC by Martin Vecera
Modified: 2011-02-17 09:38 UTC (History)
0 users

Fixed In Version:
Clone Of:
Environment:
Last Closed: 2011-02-17 09:38:52 UTC
Type: Bug
Embargoed:


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


Links
System ID Private Priority Status Summary Last Updated
Red Hat Issue Tracker SOA-2419 0 None None None Never

Description Martin Vecera 2010-10-13 16:21:46 UTC
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.

Comment 1 Martin Vecera 2010-10-13 16:22:50 UTC
Attachment: Added: slsb_action.tar.gz


Comment 2 Kevin Conner 2010-10-19 10:30:18 UTC
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 14:18:45 UTC
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 14:30:29 UTC
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 17:01:16 UTC
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 23:14:35 UTC
Link: Added: This issue is a dependency of BRMS-404


Comment 7 Tihomir Surdilovic 2010-10-20 23:16:35 UTC
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-17 00:41:26 UTC
Writer: Added: Darrin


Comment 9 Laura Bailey 2010-12-17 00:47:55 UTC
Release Notes Docs Status: Added: Not Yet Documented


Comment 11 Martin Vecera 2011-01-27 14:15:12 UTC
Verified in 5.1.0 ER8

Comment 12 Dana Mison 2011-02-17 09:38:52 UTC
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.