Re: [rules-users] Drools and Java EE

Hello; I've made a JCA resource adapter for Drools. I've had to hack quite a bit to get it so that the KnowledgeAgent- and resource-scanning-related parts don't use Threads, but, instead, use the JCA-supplied WorkManager and BootstrapContext#createTimer() for asynchronous operations (like resource scanning and notifying). Here are some changes it would sure be nice to see, that I needed to hack around in order to make it so that a KnowledgeAgent-produced KnowledgeBase could be shared by Java EE components in a specification compliant manner: 1. ResourceChangeNotifierImpl#ProcessChangetSet is an inner class that is marked as public static, but which has a package-protected constructor. I have to create a new instance of this in order to create a ResourceChangeNotifierImpl subclass that doesn't use threads. I hope this constructor could be made public instead. Right now I'm calling setAccessible(true). Yecch. 2. ResourceFactory#setFactoryService(): sure do wish this were public, or that there were another way to install a ResourceFactoryService. I need to do this so that the scanner and notifier are under my control (and don't use Threads, but instead use Timers as provided by the JCA BootstrapContext class). It appears that I do have some control here in Drools 5.1 with the (undocumented) ServiceRegistry interface (how do I get an instance of it? what does it do? is it used pervasively?), but I don't know, since it's undocumented, whether it's the preferred way to do this sort of thing or not. 3. All this indirection is really quite clunky, especially given the META-INF/services facility. Was there a good reason this was not used? I'm sure there was something, because having to consult a factory for a service to get a provider to produce an instance of something is a bit much. Hacking around those limitations, I was able to produce a Drools resource adapter that vends KnowledgeBase instances as its user connection factories. This means to use it in a spec-compliant manner, you do this in your stateless (or stateful) session bean: @Resource private KnowledgeBase kb; ...and you get injected a wrapper KnowledgeBase that uses the Java EE container's JCA machinery to invoke operations on the shared KnowledgeBase. Is this something that would be interesting to other people? If so I am happy to open source it. Thanks for a great toolkit. Best, Laird