[rules-dev] Spring support for drools-api

[Mark Proctor]

now my spring skills are improving, I'm looking to improve the xml and 
leverage spring Resource framework - so that we can get complete 
scripting of the entire KnowlegeBuilder api. I've come up with the two 
xmls so far:
      <property name="drls">
          <list>
              
<value>file:src/main/java/org/drools/ioc/spring/testSpring.drl</value>
          </list>  
      </property>    
 
      <property name="dtables">
          <list>
                  <bean 
class="org.drools.ioc.spring.DtableResourceFactoryBean">
                      <property name="resource" 
value="file:src/main/java/org/drools/ioc/spring/dt.xls" />
                      <property name="inputType" value="XLS" />
                  
</bean>                                                    
          </list>  
      </property>
This one has a property per knowledge type, the advantage is on 
knowledge types which are just string, we can use a simple <value>. 
Although knowlege tyep that require additional information, like the DT 
input type, will need a bean.

      <property name="resources">
          <list>
              <bean 
class="org.drools.ioc.spring.KnowledgeResourceBeanFactory">
                  <property name="knowledgeType" value="DRL" />
                  <property name="resource" 
value="file:src/main/java/org/drools/ioc/spring/testSpring.drl" 
/>                 
              </bean>
 
              <bean 
class="org.drools.ioc.spring.KnowledgeResourceBeanFactory">
                  <property name="knowledgeType" value="DTABLE" />
                  <property name="resource" 
value="file:src/main/java/org/drools/ioc/spring/dt.xls" />
                  <property name="resourceConfiguration">   
                      <bean 
class="org.drools.ioc.spring.DtableResourceFactoryBean">
                          <property name="inputType" value="XLS" />
                      </bean> 
                  </property>
              </bean>                     
          </list>
      </property>
This approach more closely resembles the kbuilder api. We have  simple 
resources list. Everything is a bean, so it's very flexible, but we lose 
the shortcut approach of the first one where we can just give a list of 
strings. As each one must be a bean, so that it can contain atleast the 
knowledge type, as well as the resource string.

My preference currently is for the second one, as I don't tink it's too 
verbose, and it provides better consistency than the first.

Mark


Geoffrey De Smet wrote:
> 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
>>
>
> _______________________________________________
> rules-dev mailing list
> rules-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/rules-dev
>
>