Re: [rules-dev] Spring support for drools-api
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/springframewo...
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(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/rules-dev
>
_______________________________________________
rules-dev mailing list
rules-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/rules-dev