[rules-dev] drools-spring and drools-guice

Paul Browne paulb at firstpartners.net
Tue Jan 15 03:36:57 EST 2008


Mark / Xavier

No problem with using that class under the Apache licence if needed. Do 
I need to sign in blood somewhere? :-)

That class is 'just' a simple JavaBean that wraps the Drools classes, 
allows Spring XML to configure it. Think the most simple integration 
possible.

Xavier: Is there anything that you need / how can I help?

Paul






Mark Proctor wrote:
> Paul Browne wrote:
>> Mark,
>>
>> I've already a bit of code that does simple Spring Integration (and 
>> am clear to donate it to Drools, need to change it to LGPL). Not sure 
>> what you'll think of the quality (!) but already used on a client 
>> site, might be a useful starting point.
>>
> Can we get it ASL, instead of LGPL? Xavier was on irc today, I think 
> he's going to have a crack at it too. So keep an eye out for him. Make 
> sure you read over Ales ideas that he implemented for the JBoss MC, 
> many of them are applicable.
>> http://red-piranha.svn.sourceforge.net/viewvc/red-piranha/trunk/rp-core/src/main/java/net/fp/rp/drools/SpringDecisionTableLoader.java?revision=7&view=markup 
>>
>>
>> Paul
>>
>> Mark Proctor wrote:
>>> I'd like to add two sub projects to Drools to enable better spring 
>>> and guice support - especially now we have the RuleAgent. Any 
>>> volunteers for this? I'd like to try and standardise, as much as 
>>> possible, how Drools works and integrates with IoC containers.
>>>
>>> Ultimiately the integration should be quite lightweight - mostly 
>>> about creating rulebases and working memory and probably the scoping 
>>> and caching of these. I guess you could also have some life cycle 
>>> management about objects themselves and auto assertion/retraction to 
>>> named working memories. We'd need to define a set of agreed 
>>> annotations to define these things, that would work across 
>>> containers. I believe the JBoss MC people have done some work in 
>>> this area, I have cc'd to see if they have any input or 
>>> documentation pointers.
>>>
>>> The core dev team don't have the time and aren't spring/guice 
>>> specialists - so anyone willing to take this up? If we can get 
>>> reasonable implementations we will add them to subversion (and the 
>>> authors commit rights), and make part of the next release - assuming 
>>> they are of good enough quality.
>>>
>>> So any takers, maybe we could atleast start at defining what this 
>>> level of integration should look like?
>>>
>>> Mark
>>> _______________________________________________
>>> rules-dev mailing list
>>> rules-dev at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/rules-dev
>>>
>>
>>
>> _______________________________________________
>> rules-dev mailing list
>> rules-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/rules-dev
>>
>
>





More information about the rules-dev mailing list