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@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>
          </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@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@codehaus.org> wrote:

  
From: Mark Proctor <mproctor@codehaus.org>
Subject: Re: [rules-dev] Spring support for drools-api
To: "Rules Dev List" <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/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@lists.jboss.org

            
https://lists.jboss.org/mailman/listinfo/rules-dev
    
            
          
_______________________________________________
    
rules-dev mailing list
rules-dev@lists.jboss.org

          
https://lists.jboss.org/mailman/listinfo/rules-dev
    
_______________________________________________
rules-dev mailing list
rules-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/rules-dev


        
_______________________________________________
rules-dev mailing list
rules-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/rules-dev


      
_______________________________________________
rules-dev mailing list
rules-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/rules-dev
    
      
_______________________________________________
rules-dev mailing list
rules-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/rules-dev


  

_______________________________________________
rules-dev mailing list
rules-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/rules-dev


_______________________________________________
rules-dev mailing list
rules-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/rules-dev



_______________________________________________
rules-dev mailing list
rules-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/rules-dev


_______________________________________________
rules-dev mailing list
rules-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/rules-dev