recursion checking util
                                
                                
                                
                                    
                                        by Mark Proctor
                                    
                                
                                
                                        I've been getting requests for a testing tool that checks for recursion, 
and exits the test if its detected. Any takers fancy having a go at 
this? Mostly its just an event model thing, bit like the audit view. But 
as recursion is not just about rule recursion, but Activation recursion 
too (i.e. rule recursion with the same data), you'll need to create a 
stack of rules and tuples, and check against that stack for possible 
recursions. Should be fun :)
Mark
                                
                         
                        
                                
                                17 years, 10 months
                        
                        
                 
         
 
        
            
        
        
        
                
                        
                                
                                 
                                        
                                
                         
                        
                                
                                
                                        
                                                
                                        
                                        
                                        validator
                                
                                
                                
                                    
                                        by Mark Proctor
                                    
                                
                                
                                        I'm thinking about an ontology constraint system, based around field 
setter validation. However I cannot decide how to handle invalid changes 
in a consequence or in external java code. I'll may leverage the JSR 303 
- Bean Validation - http://jcp.org/en/jsr/detail?id=303.
Although I have several concerns with the spec, one is that it always 
validates objects and passes in the field as an object - with primitive 
intensive stuff that can add an overhead, due to auto boxing. I'm more 
tempted to pass in the main Object itself and users can then use the 
FieldExtractor to read the field as they require, either as an Object or 
a primitive with full co-ercion - the FieldExtractor would be injected. 
Further to that I can't see how you would make the validator session 
aware, and doing it via constructor injection would mean a validator per 
session which is not desirable. I spoke to the spec lead and he 
mentioned using LocalThread variables. However we can have multiple 
sessions in the same thread, just not executing at the same time, which 
means the current executing session would need to set itself on that 
localthread variable - basically context switching, which I don't like.
We should have a variable that lists the validator errors for the 
current working memory action phase, for user interrogation - much like 
Hibernate Validator (RI for JSR 303) allows you to list validation 
errors on a insert or update on a session.
But in rule engines we have other considerations:
The first fundamental question is do we allow invalid changes or do we 
always roll them back? My prefernce, much like a database, is the data 
model as seen by the engine is always valid.
Now if we assume the invalid change must be rolled bank or not applied 
how do we expose this to the user:
-Throw an exception, up to them if they catch and it will exit the 
engine if not caught.
-Do nothing, roll back the change and continue executing the consequence 
as normal, they can check the validator variable if they need to.
Allow for "catch" like blocks either after each modify block, or after 
the "then" block. Do we have one large catch block, or do we have some 
sort of type matching....
Currently my preference is for a "catch" block after the "then" block. 
I'm tempted to just have one large catch block and users can do an 
iteration of the validator variable doing "if" checks; we can always add 
in type matching later. The catch block can either resume or throw an 
exception; on resumption it will attempt to validate the bean again, if 
it's changed, if it's still invalid the process repeats.
Mark
                                
                         
                        
                                
                                17 years, 10 months
                        
                        
                 
         
 
        
            
        
        
        
                
                        
                                
                                 
                                        
                                
                         
                        
                                
                                
                                        
                                                
                                        
                                        
                                        Re: [rules-dev] KnowledgeBase
                                
                                
                                
                                    
                                        by Vineet Khosla
                                    
                                
                                
                                        Peter Jackson supports the wiki concept. Knowledge base has 'both rules and various declarations'.
Lets keep it 'rule base'.
 
Vineet
----- Original Message ----
From: Massi Gmail <mmquelo(a)gmail.com>
To: rules-dev(a)lists.jboss.org
Sent: Thursday, January 3, 2008 5:49:23 AM
Subject: Re: [rules-dev] KnowledgeBase
 
 
 
Reading the wikipedia doc, It seems that a 
knowledgebase does not only contain data in a "Rule Format" but
even other kind of information. For instance 
information like the "object model".
 
As far as I understood the rulebase does not 
contain anything related to the object\fact model.
 
So I would say that the rulebase is "part of" the 
knowledge base and not the "knowledgebase" itself.
 
It's just an idea....
 
Massi
 
 
      ____________________________________________________________________________________
Looking for last minute shopping deals?  
Find them fast with Yahoo! Search.  http://tools.search.yahoo.com/newsearch/category.php?category=shopping
                                
                         
                        
                                
                                17 years, 10 months
                        
                        
                 
         
 
        
            
        
        
        
                
                        
                        
                                
                                
                                        
                                                
                                        
                                        
                                        Re: [rules-dev] KnowledgeBase
                                
                                
                                
                                    
                                        by Massi Gmail
                                    
                                
                                
                                        
Reading the wikipedia doc, It seems that a knowledgebase does not only contain data in a "Rule Format" but
even other kind of information. For instance information like the "object model".
As far as I understood the rulebase does not contain anything related to the object\fact model.
So I would say that the rulebase is "part of" the knowledge base and not the "knowledgebase" itself.
It's just an idea....
Massi
                                
                         
                        
                                
                                17 years, 10 months