>
> 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,