[rules-dev] Spring support for drools-api

[Mark Proctor]

Geoffrey De Smet wrote:
> Strong opinions:
>
> org.drools.spring.SpringKnowledgeAgentFactory
>   should be renamed to
> org.drools.spring.SpringKnowledgeAgentFactoryBean
ok, will do.
>
> See "All Known Implementing Classes" in:
> http://static.springframework.org/spring/docs/2.5.x/api/org/springframework/beans/factory/FactoryBean.html 
>
>
>
> Weak opinions:
>
> 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?
>
> How are you going to name the module? Like they do in Seam?
> => module with artifactId "drools-ioc"
> See http://repository.jboss.org/maven2/org/jboss/seam/jboss-seam-ioc/
I'd just done drools-spring, do you recommend something else? then guice 
would just be org.drools.guice.
>
> With packages like this?
>  org.drools.ioc
>  org.drools.ioc.spring
>  org.drools.ioc.guice
>  org.drools.ioc.picocontainer
>  ...
> => org.drools.ioc.spring.KnowledgeAgentFactoryBean
>
> It helps to understand it's purpose if it follows naming conventions 
> of other projects :)
I didn't know what other projects do, so if this is a convention that 
other people expect, i.e. more than just Seam, then I think we can do it.

Mark
>
> With kind regards,
> Geoffrey De Smet
>
>
> Mark Proctor schreef:
>> I've been reading about spring this weekend, in preparation of spring 
>> support for drools-api. My first attempt was using drools-api 
>> factories directly, which actually works "out of the box". Here is an 
>> example using the KnowledgeAgentFactory:
>>
>> --------beans.xml-------
>>  <bean id="agent1"        
>> class="org.drools.agent.KnowledgeAgentFactory"        
>> factory-method="newKnowledgeAgent">
>>      <constructor-arg type="java.lang.String" value="agent1"/>
>>
>>      <constructor-arg type="java.util.Properties">
>>          <props>
>>              <prop 
>> key="file">src/main/java/org/drools/springframework/testSpring.drl</prop> 
>>          </props>
>>      </constructor-arg>
>>  </bean>
>>
>> ---------testSpring.drl---------
>> package  org.drools.springframework
>>
>> rule "rule 1"
>> when
>> then
>>    System.out.println( "hello world" );
>> end
>> ---------test--------- Resource resource = new FileSystemResource( 
>> "src/main/java/org/drools/springframework/beans.xml" 
>> );                 BeanFactory factory = new XmlBeanFactory( resource );
>> KnowledgeAgent agent1 = ( KnowledgeAgent ) factory.getBean( "agent1" );
>> agent1.getKnowledgeBase().newStatelessKnowledgeSession().executeObject( 
>> "test" );
>>
>>
>> Sow I was quite impressed how easy that was to get working, but 
>> people like the "Spring" way. So I made a custom 
>> SpringKnowledgeAgentFactory that implements FactoryBean. So now the 
>> above beans.xml can look like the following:
>>  <bean id="agent1" 
>> class="org.drools.spring.SpringKnowledgeAgentFactory">
>>      <property name="name" value="agent1"/>
>>      <property name="file" 
>> value="src/main/java/org/drools/spring/testSpring.drl" />
>>  </bean>
>>
>> Which is much less verbose. So I think I'll take some time tomorrow 
>> to do FactoryBean implementations for all main user factories from 
>> drools-api, shouldn't take long and then we have out of the box 
>> spring support. Anyone have any feedback, it seems that now that we 
>> have drools-api, which provides complete implementation/interface 
>> separation, and Spring only needs to return interfaces, this is all 
>> we need to do. If it's quick to do, I might have a go at doing one 
>> for Guice too.
>>
>> 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
>
>