Re: [rules-dev] Spring support for drools-api

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