[rules-dev] Spring support for drools-api

[Geoffrey De Smet]

It doesn't indeed sound overkill to me to create a FactoryBean for the 
Builder.
Though I would probably reuse the Builder inside the 
KnowlegdeBaseFactory to build the Knowlegde base.

The real issue is concurrency.
Spring promotes the idea of stateless beans which do have global 
variables, but those global variables are either synchronised 
thread-safe or also follow the stateless bean pattern.
This in fact makes the stateless beans thread safe, without any need for 
synchronization/locking.

So the question is: is your KnowlegdeBase thread-safe?
Thread safe objects are usually put into global variables,
while not thread unsafe objects are always put into local variables.

class A {
   private B b; // thread-safe by synchronization (JDBCConnection, ...)
   private C c; // thread-safe by the stateless pattern:

   // both b and c are set during initialization (constr. or setter), 
before A is exposed to other threads

   public void metho(D d) { // d is not thread-safe
     E e = ...; // e is not thread-safe
   }

}

In drools 4. B is the RuleBase, while E is the working memory instance.

With kind regards,
Geoffrey De Smet


Mark Proctor schreef:
> Geoffrey De Smet wrote:
>>
>> With kind regards,
>> Geoffrey De Smet
>>
>>
>> Mark Proctor schreef:
>>
>>>> I'd also maybe consider dropping the Spring prefix, as it's in a 
>>>> package called spring?
>>>> => org.drools.spring.KnowledgeAgentFactoryBean
>>> My worry here is it might be a duplicate of the same name used in the 
>>> future - although it'll be in a different package namespace, it's 
>>> still not good practice. Anyone else have any opinions on this?
>>
>> Good point, prefixing it with Spring can't hurt :)
> I'm just wondering about KnowledgeBuilderFactory and 
> KnowledgeBaseFactory. While it makes sense to put the 
> KnowledgeAgentFactory into spring, does it make sense for those other 
> factories? What are they gonna do other than return KnowledgeBuilder or 
> a KnowledgeBase, only possible advantage is that it would allow spring 
> to inject the KnowledgeBuilderConfiguration and 
> KnowledgeBaseConfiguration. And ideas?
> http://anonsvn.labs.jboss.com/labs/jbossrules/trunk/drools-api/src/main/java/org/drools/builder/KnowledgeBuilderFactory.java 
> 
> http://anonsvn.labs.jboss.com/labs/jbossrules/trunk/drools-api/src/main/java/org/drools/builder/KnowledgeBuilder.java 
> 
> 
> http://anonsvn.labs.jboss.com/labs/jbossrules/trunk/drools-api/src/main/java/org/drools/KnowledgeBaseFactory.java 
> 
> http://anonsvn.labs.jboss.com/labs/jbossrules/trunk/drools-api/src/main/java/org/drools/KnowledgeBase.java 
> 
> 
> This is typically how those two factories are used:
> KnowledgeBuilder kbuilder = KnowledgeBuilderFactory.newKnowledgeBuilder();
> kbuilder.addResource( new URL( "file://myrules.drl" ),
>                                   KnowledgeType.DRL);
> KnowledgeBase kbase = KnowledgeBaseFactory.newKnowledgeBase();
> 
> If we use spring to automate the adding of resources, that's pretty much 
> what the agent is doing anyway, so wouldn't that be pointless?
> 
> 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
>