[rules-dev] Spring support for drools-api
Mark Proctor
mproctor at codehaus.org
Tue Nov 25 01:07:09 EST 2008
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> wrote:
>>
>>
>>> From: Mark Proctor <mproctor at codehaus.org>
>>> Subject: Re: [rules-dev] Spring support for drools-api
>>> To: "Rules Dev List" <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 list
>>>>>>> rules-dev at lists.jboss.org
>>>>>>>
>>>>>>>
>>> https://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 list
>>>>> rules-dev at lists.jboss.org
>>>>> https://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 list
>>> rules-dev at lists.jboss.org
>>> https://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 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/20081125/204c8c7f/attachment.html
More information about the rules-dev
mailing list