[rules-dev] Spring support for drools-api
Michal Bali
michalbali at gmail.com
Tue Nov 25 20:10:57 EST 2008
Sounds good. Thanks Mark. I probably won't find time until I finish writing
the book. It should be no problem after I finish.
On Tue, Nov 25, 2008 at 4:02 PM, Mark Proctor <mproctor at codehaus.org> wrote:
> I'm going to get the basics done, then I'm really hoping that you or paul
> or someone else will pick up the rest and polish it off (like your
> suggestion below) and do javadocs - as I need to get on with core work - I'm
> just trying to get the ball rolling.
>
> I'll try and have something committed today, that you people can roll with.
>
> Mark
> Michal Bali wrote:
>
> Hi,
>
> I think the xml looks good.
> Spring's PropertyEditors -
> http://static.springframework.org/spring/docs/2.5.x/reference/validation.html#beans-beans-conversion 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 at 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 at codehaus.org> <mproctor at codehaus.org> wrote:
>>
>>
>>
>> From: Mark Proctor <mproctor at codehaus.org> <mproctor at codehaus.org>
>> Subject: Re: [rules-dev] Spring support for drools-api
>> To: "Rules Dev List" <rules-dev at lists.jboss.org> <rules-dev at 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/java/org/drools/builder/KnowledgeBuilderFactory.java
>>
>> http://anonsvn.labs.jboss.com/labs/jbossrules/trunk/drools-api/src/main/java/org/drools/builder/KnowledgeBuilder.java
>>
>> http://anonsvn.labs.jboss.com/labs/jbossrules/trunk/drools-api/src/main/java/org/drools/KnowledgeBaseFactory.java
>>
>> http://anonsvn.labs.jboss.com/labs/jbossrules/trunk/drools-api/src/main/java/org/drools/KnowledgeBase.java
>>
>> 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 listrules-dev at lists.jboss.org
>>
>> https://lists.jboss.org/mailman/listinfo/rules-dev
>>
>> _______________________________________________
>>
>>
>> rules-dev mailing listrules-dev at lists.jboss.org
>>
>> https://lists.jboss.org/mailman/listinfo/rules-dev
>>
>> _______________________________________________
>> rules-dev mailing listrules-dev at lists.jboss.orghttps://lists.jboss.org/mailman/listinfo/rules-dev
>>
>>
>> _______________________________________________
>> rules-dev mailing listrules-dev at lists.jboss.orghttps://lists.jboss.org/mailman/listinfo/rules-dev
>>
>>
>> _______________________________________________
>> rules-dev mailing listrules-dev at lists.jboss.orghttps://lists.jboss.org/mailman/listinfo/rules-dev
>>
>>
>> _______________________________________________
>> rules-dev mailing listrules-dev at lists.jboss.orghttps://lists.jboss.org/mailman/listinfo/rules-dev
>>
>>
>>
>> ------------------------------
>> _______________________________________________
>> rules-dev mailing listrules-dev at lists.jboss.orghttps://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
>>
>>
> ------------------------------
>
> _______________________________________________
> rules-dev mailing listrules-dev at lists.jboss.orghttps://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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/rules-dev/attachments/20081126/b92508fd/attachment.html
More information about the rules-dev
mailing list