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 <[email protected]> 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 > [email protected] > https://lists.jboss.org/mailman/listinfo/rules-dev > > -- Michael D Neale home: www.michaelneale.net blog: michaelneale.blogspot.com
_______________________________________________ rules-dev mailing list [email protected] https://lists.jboss.org/mailman/listinfo/rules-dev
