I've cleaned up (somewhat) my source and dumped it at <a href="https://code.google.com/p/drools-jca/source/checkout" target="_blank">https://code.google.com/p/drools-jca/source/checkout</a>.<br><br>This
is a project that attempts (successfully as far as I can tell but who
knows) to make Drools a Java EE citizen by way of the JCA specification.<br>
<br>The way that I've implemented the resource adapter relies (at the moment) on several make-a-private-method-<div id=":13s">accessible hacks in Drools 5.1.0.<br><br>Among
other things I've brutally hacked out the sections of Drools that rely
on Threads and have subclassed and whatnot so that they now use the
JCA-mandated WorkManager and BootstrapContext#getTimer().<br>
<br>The resource adapter sets up a KnowledgeAgent which consults a
changeset and monitors it. When a new KnowledgeBase is detected, the
agent rebuilds it. Client calls are blissfully unaware of all of this.<br><br>The
general gist of the project is that you should, from an EJB, be able to
do this, provided your container is set up properly:<br>
<br>@Resource<br>private KnowledgeBase kb;<br><br>...and that KnowledgeBase will be a "front" for the "real" KnowledgeBase managed by the resource adapter.<br><br>I've
declared the resource adapter as not supporting transactions, because
it's unclear to me what it would mean for it to do so. One area that is
unexplored is what happens if you are in a transaction in your EJB, and
you stuff your EJB's copy of, say, an EntityManager into the rules as a
global. Does "not supporting transactions" mean that the transaction
of which the EntityManager was most recently a part will be suspended?
Or is this sleight-of-hand possible?<br>
<br>As confirmed on the rules-user list, no further synchronization or
anything like that is (apparently) necessary from a caller's point of
view.<br><br>The project is built in two parts: the raw jars part
(drools-jca) and the RAR wrapper around it (drools-rar). This allows the
drools-jca part to be tested by an embedded instance of OpenEJB, which
is a Java EE 6 compliant (mostly) application server. It also allows
the consumer to decide whether to build his own "skinny" rar or to use
the drools-rar project as is.<br>
<br>Please please please give me feedback on this in case I've done something horribly wrong.<br><br>Best,<br><font color="#888888">Laird</font></div>