11:38 a.m.
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
11:18 p.m.
I think it is an interesting idea. I haven't ever used JCA - and I, like
most others, kind of turn a blind eye to things that are technically
"naughty" in JEE land, but it is interesting that JCA offers ways to allow
this. I think there might be a bunch of people interested in this - sounds
like a lot of work to maintain though?
On Thu, Aug 26, 2010 at 2:38 AM, Laird Nelson <ljnelson(a)gmail.com> wrote:
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
_______________________________________________
rules-dev mailing list
rules-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/rules-dev
--
Michael D Neale
home: www.michaelneale.net
blog: michaelneale.blogspot.com
4989
days inactive
4990
days old
1 comments
2 participants
participants (2)
-
Laird Nelson -
Michael Neale