[rules-dev] Spring support for drools-api

[Mark Proctor]

I'm thinking of adopting the Spring approach to Resources for 
drools-api, obviously not tieing drools-api to spring - just copying the 
concept. Resource however doesn't seem to work with Readers. Readers in 
general are only needed for in memory generation , using StringReader, 
otherwise file/url/classpath resources suffice. So it seems to do the 
Spring way you would do a ByteArrayResource( "this is my drl 
file".getBytes() ). I'm wondering what people think of that, and what 
about encoding issues? Compared to the way at the moment that we just 
take a Reader, and that's it.

Mark

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