Strong opinions: org.drools.spring.SpringKnowledgeAgentFactory should be renamed to org.drools.spring.SpringKnowledgeAgentFactoryBean

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

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/

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 :)

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

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 :)

_______________________________________________ rules-dev mailing list rules-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/rules-dev

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/j... > > http://anonsvn.labs.jboss.com/labs/jbossrules/trunk/drools-api/src/main/j... > > > http://anonsvn.labs.jboss.com/labs/jbossrules/trunk/drools-api/src/main/j... > > http://anonsvn.labs.jboss.com/labs/jbossrules/trunk/drools-api/src/main/j... > > > 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(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 > _______________________________________________ rules-dev mailing list rules-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/rules-dev

From: Mark Proctor <mproctor(a)codehaus.org&gt; Subject: Re: [rules-dev] Spring support for drools-api To: "Rules Dev List" <rules-dev(a)lists.jboss.org&gt; Date: Sunday, November 23, 2008, 9:09 PM 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/j... >>> >>> http://anonsvn.labs.jboss.com/labs/jbossrules/trunk/drools-api/src/main/j... >>> >>> >>> http://anonsvn.labs.jboss.com/labs/jbossrules/trunk/drools-api/src/main/j... >>> >>> http://anonsvn.labs.jboss.com/labs/jbossrules/trunk/drools-api/src/main/j... >>> >>> >>> 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(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 >>> >> >> _______________________________________________ >> 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 > > _______________________________________________ rules-dev mailing list rules-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/rules-dev

I'm updating drools-api as we speak, based on the spring Resource idea. the following Factory will provide a set of ready to go Resources, that should satisfy most people's needs. So drools-api will be spimplied to kbuilder.addResource( Resource, KnowledgeType ) kbuilder.addResource( Resource, KnowledgeType, ResourceConfiguration ) And the Resources available, and ofcourse people can implement the interface themselves is: public class ResourceFactory { public static Resource newURLResource(URL url) { return null; } public static Resource newURLResource(URI uri) { return null; } public static Resource newURLResource(String url) { return null; } public static Resource newFileResource(File file) { return null; } public static Resource newFileResource(String file) { return null; } public static Resource newByteArrayResource(byte[] bytes) { return null; } public static Resource newInputStreamResource(InputStream stream) { return null; } public static Resource newReaderResource(Reader reader) { return null; } public static Resource newReaderResource(Reader reader, String encoding) { return null; } public static Resource newClassPathResource(String path) { return null; } public static Resource newClassPathResource(String path, ClassLoader classLoader) { return null; } } It can take a Reader, which underneath will open an InputStream, it'll use default encoding unless the encoding is specified as otherwise in the alternative param. So typically it'll be kbuilder.addResource( ResourceFactory.newClassPathResource( "some path" ), KnowledgeType.DRL ); don't forget you can import static methods, so it can actually be: kbuilder.addResource( newClassPathResource( "some path" ), KnowledgeType.DRL ); Mark Greg Barton wrote: > Well, if you look at String.getBytes() it uses the default encoding, then ISO-8859-1 if that fails. (Default is UTF-8 unless otherwise specified in the "file.encoding" property.) As long as that's documented I guess it's not a problem, unless someone wants to specify their own charset for a particular file. Java 1.6 has String.getBytes(Charset) and that could allow someone to use an alternate charset. > > I figure for the vast majority of cases it won't be a problem. > > --- On Sun, 11/23/08, Mark Proctor <mproctor(a)codehaus.org&gt; wrote: > > >> From: Mark Proctor <mproctor(a)codehaus.org&gt; >> Subject: Re: [rules-dev] Spring support for drools-api >> To: "Rules Dev List" <rules-dev(a)lists.jboss.org&gt; >> Date: Sunday, November 23, 2008, 9:09 PM >> 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/j... >> >> >>>>> >> http://anonsvn.labs.jboss.com/labs/jbossrules/trunk/drools-api/src/main/j... >> >> >>>>> >> http://anonsvn.labs.jboss.com/labs/jbossrules/trunk/drools-api/src/main/j... >> >> >>>>> >> http://anonsvn.labs.jboss.com/labs/jbossrules/trunk/drools-api/src/main/j... >> >> >>>>> 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(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 >> >>>> _______________________________________________ >>>> 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 >>> >>> >>> >> _______________________________________________ >> 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 > > > ------------------------------------------------------------------------ _______________________________________________ rules-dev mailing list rules-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/rules-dev

Hi, I think the xml looks good. Spring's PropertyEditors - http://static.springframework.org/spring/docs/2.5.x/reference/validation.... could be used to even further simplify it. Using convention over configuration to guess the resource type from file's extension. The configuration will then become: <bean id="rb1" class="org.drools.ioc.spring.KnowledgeBaseFactoryBean"> <property name="resources"> <list> <value>file:src/main/java/org/drools/ioc/spring/testSpring.drl</value> <value>file:src/main/java/org/drools/ioc/spring/IntegrationExampleTest.xls</value> </list> </property> </bean> I am not that familiar with PropertyEditors to know if this is possible to do or not. I am just throwing it out here, maybe somebody else will know better. It is not that important just nice to have.. Best Regards, Michal On Tue, Nov 25, 2008 at 6:07 AM, Mark Proctor <mproctor(a)codehaus.org <mailto:mproctor@codehaus.org>> wrote: This is now what the spring XML looks like: <bean id="rb1" class="org.drools.ioc.spring.KnowledgeBaseFactoryBean"> <property name="resources"> <list> <bean class="org.drools.ioc.spring.KnowledgeResourceFactoryBean"> <property name="knowledgeType" value="DRL" /> <property name="source" value="file:src/main/java/org/drools/ioc/spring/testSpring.drl" /> </bean> <bean class="org.drools.ioc.spring.KnowledgeResourceFactoryBean"> <property name="knowledgeType" value="DTABLE" /> <property name="source" value="file:src/main/java/org/drools/ioc/spring/IntegrationExampleTest.xls" /> <property name="knowledgeResourceConfiguration"> <bean class="org.drools.ioc.spring.DTableResourceConfigurationFactoryBean"> <property name="inputType" value="XLS" /> </bean> </property> </bean> </list> </property> </bean> How is that looking? Most people happy with that, it's very generic. I've dropped the agent side for the moment, just focusing on scripting of a KnowledgeBase via spring. It now more closely follows the KnowedgeBuilder api. The above spring configuration will return a rulebase of two resources, on is a simple DRL, the other is a decisiontable of type XLS. I'll extend this further to make sure that ALL knowledge types can be built for a knowledge base via the spring api. I'll also make sure it can take a KnowledgeBaseConfiguration and KnowledgeBuilderConfiguration. Then I'll also make sure there is a spring configuration to return a stateful or stateless session given a knowlebasefactorybean ref. Finally I might add some basic agent facilities. I think this should give spring users everything they need, i.e. the capability to build knowledge bases and wire sessions and knowledge bases to other beans - all via xml. Mark Mark Proctor wrote: > I'm updating drools-api as we speak, based on the spring Resource > idea. the following Factory will provide a set of ready to go > Resources, that should satisfy most people's needs. So drools-api > will be spimplied to > kbuilder.addResource( Resource, KnowledgeType ) > kbuilder.addResource( Resource, KnowledgeType, > ResourceConfiguration ) > > And the Resources available, and ofcourse people can implement > the interface themselves is: > public class ResourceFactory { > > public static Resource newURLResource(URL url) { > return null; > } > > public static Resource newURLResource(URI uri) { > return null; > } > > public static Resource newURLResource(String url) { > return null; > } > > public static Resource newFileResource(File file) { > return null; > } > > public static Resource newFileResource(String file) { > return null; > } > > > public static Resource newByteArrayResource(byte[] bytes) { > return null; > } > > public static Resource newInputStreamResource(InputStream stream) { > return null; > } > > public static Resource newReaderResource(Reader reader) { > return null; > } > > public static Resource newReaderResource(Reader reader, String encoding) { > return null; > } > > public static Resource newClassPathResource(String path) { > return null; > } > > public static Resource newClassPathResource(String path, ClassLoader classLoader) { > return null; > } > > } > > It can take a Reader, which underneath will open an InputStream, it'll use default encoding unless the encoding is > specified as otherwise in the alternative param. > > So typically it'll be > kbuilder.addResource( ResourceFactory.newClassPathResource( "some path" ), KnowledgeType.DRL ); > > don't forget you can import static methods, so it can actually be: > kbuilder.addResource( newClassPathResource( "some path" ), KnowledgeType.DRL ); > > > Mark > > > > > Greg Barton wrote: >> Well, if you look at String.getBytes() it uses the default encoding, then ISO-8859-1 if that fails. (Default is UTF-8 unless otherwise specified in the "file.encoding" property.) As long as that's documented I guess it's not a problem, unless someone wants to specify their own charset for a particular file. Java 1.6 has String.getBytes(Charset) and that could allow someone to use an alternate charset. >> >> I figure for the vast majority of cases it won't be a problem. >> >> --- On Sun, 11/23/08, Mark Proctor <mproctor(a)codehaus.org&gt; <mailto:mproctor@codehaus.org> wrote: >> >> >>> From: Mark Proctor <mproctor(a)codehaus.org&gt; <mailto:mproctor@codehaus.org> >>> Subject: Re: [rules-dev] Spring support for drools-api >>> To: "Rules Dev List" <rules-dev(a)lists.jboss.org&gt; <mailto:rules-dev@lists.jboss.org> >>> Date: Sunday, November 23, 2008, 9:09 PM >>> 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/j... >>> >>> >>>>>> >>> http://anonsvn.labs.jboss.com/labs/jbossrules/trunk/drools-api/src/main/j... >>> >>> >>>>>> >>> http://anonsvn.labs.jboss.com/labs/jbossrules/trunk/drools-api/src/main/j... >>> >>> >>>>>> >>> http://anonsvn.labs.jboss.com/labs/jbossrules/trunk/drools-api/src/main/j... >>> >>> >>>>>> 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(a)lists.jboss.org <mailto:rules-dev@lists.jboss.org> >>>>>>> >>>>>>> >>> https://lists.jboss.org/mailman/listinfo/rules-dev >>> >>>>>>> >>>>>> >>> _______________________________________________ >>> >>>>>> rules-dev mailing list >>>>>> rules-dev(a)lists.jboss.org <mailto:rules-dev@lists.jboss.org> >>>>>> >>>>>> >>> https://lists.jboss.org/mailman/listinfo/rules-dev >>> >>>>> _______________________________________________ >>>>> rules-dev mailing list >>>>> rules-dev(a)lists.jboss.org <mailto:rules-dev@lists.jboss.org> >>>>> https://lists.jboss.org/mailman/listinfo/rules-dev >>>>> >>>>> >>>>> >>>> _______________________________________________ >>>> rules-dev mailing list >>>> rules-dev(a)lists.jboss.org <mailto:rules-dev@lists.jboss.org> >>>> https://lists.jboss.org/mailman/listinfo/rules-dev >>>> >>>> >>>> >>> _______________________________________________ >>> rules-dev mailing list >>> rules-dev(a)lists.jboss.org <mailto:rules-dev@lists.jboss.org> >>> https://lists.jboss.org/mailman/listinfo/rules-dev >>> >> >> _______________________________________________ >> rules-dev mailing list >> rules-dev(a)lists.jboss.org <mailto:rules-dev@lists.jboss.org> >> https://lists.jboss.org/mailman/listinfo/rules-dev >> >> >> > > ------------------------------------------------------------------------ > _______________________________________________ rules-dev mailing > list rules-dev(a)lists.jboss.org <mailto:rules-dev@lists.jboss.org> > https://lists.jboss.org/mailman/listinfo/rules-dev _______________________________________________ rules-dev mailing list rules-dev(a)lists.jboss.org <mailto:rules-dev@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