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

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