[rules-dev] Drools JCA project

[Laird Nelson]

I've cleaned up (somewhat) my source and dumped it at
https://code.google.com/p/drools-jca/source/checkout.

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.

The way that I've implemented the resource adapter relies (at the moment) on
several make-a-private-method-
accessible hacks in Drools 5.1.0.

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().

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.

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:

@Resource
private KnowledgeBase kb;

...and that KnowledgeBase will be a "front" for the "real" KnowledgeBase
managed by the resource adapter.

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?

As confirmed on the rules-user list, no further synchronization or anything
like that is (apparently) necessary from a caller's point of view.

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.

Please please please give me feedback on this in case I've done something
horribly wrong.

Best,
Laird
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/rules-dev/attachments/20100825/6f843c60/attachment.html