I'm tracking down a nasty bug in our Drools resource adapter.
I have a SLSB that gets an instance of a Drools KnowledgeBase. This serves as a JCA connection factory. The .rar is spec-compliant and is packaged in an .ear file. Regular readers of the forums will be very familiar with this description. :-)
The SLSB gets a handle on this KnowledgeBase like this:
[code]
@Resource
private KnowledgeBase kb;
[/code]
Now, the next thing you do in Drools is to ask the KnowledgeBase for a knowledge session. Into that you insert "facts"--Java objects. Your KnowledgeBase is a front for a Drools rule file that contains rules that run against the facts.
Much to our surprise, we can see the the rules file is loading and is successfully compiled. But none of the rules--even dummy test rules that test brain dead conditions--fire. Rules that test nothing, e.g. "eval(true)", fire just fine.
Since rule activation is driven by equality matching, it suddenly dawned on me with a deep foreboding that maybe the classloader used by the resource adapter--to compile the rules file, and hence one that needs to load classes at compilation time--is NOT the same classloader as the EJB classloader.
Is there any guarantee about classloader hierarchies between resource adapters and EJBs?
Thanks,
Laird
[Message sent by forum member 'ljnelson']
http://forums.java.net/jive/thread.jspa?messageID=485525