Paul Browne wrote:
I'll bite, although most likely I'm missing something obvious
Code sample itself is clear enough (and builds cleanly with maven),
and I *think* I can see the intention from the various Spring aspects
and config files (although I'm not sure of the purpose of the aspects.
Looking at the example (DroolsTest.java) what I see is the Drools
classes being loaded pretty much as normal (no Spring)
What I expected to see in the sample was:
1) Test gets a handle to the Spring config file
2) Spring auto-configuring the beans based on the contents of this file..
3) A call (via a bean that we've obtained from the Spring Context)
which causes the Rule engine to fire
4) A 2nd config file showing how to configure Spring transactions /
What can I do to help? Given that this isn't in SVN yet , what's the
best way to manage the code?
I know nothing about spring. But it people believe
this is a good
starting base, I'll create a branch and add it in so people can work on
it. So shall I add this now?
Mark Proctor wrote:
> -------- Original Message --------
> You can declare the transaction beans as follows:
> <bean id="droolsTransactionManager"
> <property name="workingMemory" ref="workingMemory"/>
> <bean id="txProxyTemplate" abstract="true"
> <property name="proxyTargetClass">
> <property name="transactionManager"
> <property name="transactionAttributes">
> The last one is only a proxy for the transaction, to declare the
> I think the classes for aspects in Ales implementation can be
> implemented this way for spring, if not it will be needed to look at :
> but I need time for that.
> The DroolsTransactionManager is for standalone use.
> It was added rule base configuration support for the bean factory of
> Geoffrey as well to set the type.
> Here are information about getting Resources like URL, input stream,
> rules-dev mailing list
rules-dev mailing list