[rules-users] Dynamic JavaBeans

Felipe Piccolini felipe.piccolini at bluesoft.cl
Fri Jun 29 18:41:57 EDT 2007 

Wel... making more tests... I think i was wrong about dynamic  
JavaBeans... I dont think the problem is there...
using update($fact) after modify makes the same issue...

Consider this:
//-------FACT-----------------------------
public class Fact implements Serializable {
	private static final long serialVersionUID = 331627137981862975L;
	
	private int number;
	
	public Fact(int number){
		this.number	= number;
	}
	
	public Fact(){
		this(0);
	}

	/**
	 * @return the number
	 */
	public int getNumber() {
		return number;
	}

	/**
	 * @param number the number to set
	 */
	public void setNumber(int number) {
		this.number = number;
	}
	
}

//-------RULES-----------------------------
package cl.bluesoft.test

#list any import classes here.
import java.util.List
import java.util.ArrayList

import cl.bluesoft.test.rules.Fact

#declare any global variables here

rule "test update A"
     salience 699
     no-loop
	when
		$f : Fact($n: number > 0)
		$list: ArrayList( this excludes "key1")
	then
		System.out.println("A-fact number1:"+$f.getNumber()+" list 1:"+$list);
		$list.add("key1");
		$f.setNumber($n + 1);
		update ($f);
		update ($list);
		System.out.println("A-fact number2:"+$f.getNumber()+" list 2:"+$list);
end


rule "test update B"
     salience 699
     no-loop
	when
		$f : Fact($n: number > 1)
		$list: ArrayList( this excludes "key2")
	then
		System.out.println("B-fact number1:"+$f.getNumber()+" list 1:"+$list);
		$list.add("key2");
		$f.setNumber($n + 1);
		update ($f);
		update ($list);
		System.out.println("B-fact number2:"+$f.getNumber()+" list 2:"+$list);
end

//------TEST---------
public class TestUpdateFact implements Serializable {

	private static final long serialVersionUID = -574789596641083743L;

	/**
	 * @param args
	 */
	public static void main(String[] args) {
		RuleBase ruleBase = RuleBaseFactory.newRuleBase();
		Package pkg = builder.getPackage();
		....
		WorkingMemory session = ruleBase.getStatefulSession();
		...etc etc...

		List list = new ArrayList();
		
		Fact fact1 = new Fact(1);

		session.fireAllRules();

		....etc, etc...
		
	}

}

//--------OUTPUT------------
A-fact number1:1 list 1:[]
A-fact number2:2 list 2:[key1]
B-fact number1:2 list 1:[key1]
B-fact number2:3 list 2:[key1, key2]
A-fact number1:3 list 1:[key1, key2]
A-fact number2:4 list 2:[key1, key2, key1]
B-fact number1:4 list 1:[key1, key2, key1]
B-fact number2:5 list 2:[key1, key2, key1, key2]
A-fact number1:5 list 1:[key1, key2, key1, key2]
A-fact number2:6 list 2:[key1, key2, key1, key2, key1]
B-fact number1:6 list 1:[key1, key2, key1, key2, key1]
B-fact number2:7 list 2:[key1, key2, key1, key2, key1, key2]
A-fact number1:7 list 1:[key1, key2, key1, key2, key1, key2]
A-fact number2:8 list 2:[key1, key2, key1, key2, key1, key2, key1]
B-fact number1:8 list 1:[key1, key2, key1, key2, key1, key2, key1]

.... for ever.....

So I have a loop... only when I use update and both rules...   
condition about the
list not containing "key1" and "key2" seems not properly chequed... I  
dont know...

Can somebody help me? I am missiong something here?

Thanks.


On 29-06-2007, at 17:33, Felipe Piccolini wrote:

>
> Mark,
>
>    I'v been trying to get the way to patch that, but I must confess  
> that is way too complex for me now.. My best
> guess is that when the update(retract/insert) is done, it just take  
> the factHandle modified to rebuild the ReteRuleBase
> so when the activations are setted in place this doesnt care about  
> another fact update to fill the AgendaGroupImpl.
>
>   I dont really know the best way to modify the code... I bow  
> before u guys...
>
>  Also tried your suggestion using something like : modify  
> ( cheese ) { price = 25, quality = premium }
>
>  But I get compilation erros saying that "modify(myFact) is not  
> defined"... so I dont really know how to use
> this MVEL functionality... got ur "what is new in drools 4.0",  
> search at examples and mailing-list, but cant get the right way
> to make that work.
>
>   If you could help me with any working example, or maybe a work- 
> around... I sont wanna use a set of rules that must be writen in a
> sequence mode using salience.... I need to write a lot of rules in  
> an independent way.
>
> Sorry for my english, and thank you very much.
>
>
> On 28-06-2007, at 16:43, Mark Proctor wrote:
>
>> feel free to work on a patch for us and let us know what you come  
>> up with.
>>
>> Mark
>> Felipe Piccolini wrote:
>>> Mark,
>>>
>>>    What about my previous mail where I report an issue with  
>>> update using dynamic JavaBeans (using propertyListeners)?
>>>
>>> The problem is that when the engine is fired again from an  
>>> propertyListener the evaluations on conditions (seems to me)
>>> dont take the new state of the Facts changed in the  
>>> set<Attribute> call.
>>>
>>> I will try using MVEL modify, but thats not the better solution,  
>>> because the feature of propertyListerners inside javaBeans let
>>> me write my rules in a cleaner way from BRMS/bussines editor.
>>>
>>> Thanks.
>>>
>>>
>>> On 28-06-2007, at 8:28, Mark Proctor wrote:
>>>
>>>> If it can be done cleanly I'm not averse to it. however there is  
>>>> something else...
>>>> In the new MVEL dialect you no longer need  
>>>> propertychangelisteners if you don't want to call update()
>>>>
>>>> modify ( cheese ) { price = 25, quality = premium }
>>>>
>>>> This will modify all the setters and notify the engine at the  
>>>> end of the block setter. Is that good enough for you?
>>>>
>>>> Mark
>>>> Yuri de Wit wrote:
>>>>> Mark,
>>>>>
>>>>> btw, If this is a feature that makes sense from Drools pov I  
>>>>> wouldnt
>>>>> mind giving a shot at implementing it and contributing it back to
>>>>> Drools.
>>>>>
>>>>> -- yuri
>>>>>
>>>>> On 6/28/07, Yuri de Wit <ydewit at gmail.com> wrote:
>>>>>> Sure. The solution I am taking right now is dont use dynamic
>>>>>> properties, which is not optimal (depending on the problem  
>>>>>> property
>>>>>> changes not being batched defeats the purpose of dynamic beans).
>>>>>>
>>>>>> The bottom line is that I was hoping that this feature would (1)
>>>>>> either already be taken care of in 4.0 or (2) become a feature  
>>>>>> request
>>>>>> for future releases.
>>>>>>
>>>>>> -- yuri
>>>>>>
>>>>>> On 6/28/07, Mark Proctor <mproctor at codehaus.org> wrote:
>>>>>> > No we don't do anything to batch property change listener  
>>>>>> results. But
>>>>>> > maybe you can do this yourself.
>>>>>> > instead of calling modify, add it to a transaction list  
>>>>>> (that you make
>>>>>> > available in the current context). Then at the end of the  
>>>>>> consequence
>>>>>> > you can iterate that list and call modify on each object. Or
>>>>>> > alternatively don't use dynamic properties.
>>>>>> >
>>>>>> > Mark
>>>>>> > Yuri de Wit wrote:
>>>>>> > > I am not talking about assert, but modify. I have a  
>>>>>> dynamic fact
>>>>>> > > already asserted but now I need to perform N changes on N  
>>>>>> different
>>>>>> > > properties on the same object on the same consequence.  
>>>>>> Drools is going
>>>>>> > > to traverse the RETE network N times once for each time the
>>>>>> > > PropertiesListener is called (each setProperty called).
>>>>>> > >
>>>>>> > > -- yuri
>>>>>> > >
>>>>>> > > On 6/28/07, Mark Proctor <mproctor at codehaus.org> wrote:
>>>>>> > >> Why would doing the assert work at the end of the  
>>>>>> consequence be any
>>>>>> > >> quicker than doing it during the consequence?
>>>>>> > >>
>>>>>> > >> Mark
>>>>>> > >> Yuri de Wit wrote:
>>>>>> > >> > I noticed that changes performed on facts asserted  
>>>>>> dynamically causes
>>>>>> > >> > the fact to be modified right away and therefore  
>>>>>> triggering a RETE
>>>>>> > >> > network traversal and rule schedulings.
>>>>>> > >> >
>>>>>> > >> > For apps with a large number of facts this could be a  
>>>>>> significant
>>>>>> > >> > scalability problem. At least in my case, I would like  
>>>>>> to be able to
>>>>>> > >> > use dynamic facts and perform any number of updates and  
>>>>>> have those
>>>>>> > >> > updates commited to working memory only when the rule  
>>>>>> consequence is
>>>>>> > >> > completed.
>>>>>> > >> >
>>>>>> > >> > Looking at the code, it seems that it would not be a  
>>>>>> major effort to
>>>>>> > >> > collect the facts received by the  
>>>>>> ReteooWorkingMemory.propertyChange
>>>>>> > >> > and perform the actual modifyObject() only when the  
>>>>>> consequence
>>>>>> > >> > evaluation is actually completed.
>>>>>> > >> >
>>>>>> > >> > Does that makes sense? Or are there side effects I am  
>>>>>> not seeing? Is
>>>>>> > >> > this a problem that 4.0 already resolves?
>>>>>> > >> >
>>>>>> > >> > thanks in advance,
>>>>>> > >> >
>>>>>> > >> > -- yuri
>>>>>> > >> > _______________________________________________
>>>>>> > >> > rules-users mailing list
>>>>>> > >> > rules-users at lists.jboss.org
>>>>>> > >> > https://lists.jboss.org/mailman/listinfo/rules-users
>>>>>> > >> >
>>>>>> > >>
>>>>>> > >> _______________________________________________
>>>>>> > >> rules-users mailing list
>>>>>> > >> rules-users at lists.jboss.org
>>>>>> > >> https://lists.jboss.org/mailman/listinfo/rules-users
>>>>>> > >>
>>>>>> > > _______________________________________________
>>>>>> > > rules-users mailing list
>>>>>> > > rules-users at lists.jboss.org
>>>>>> > > https://lists.jboss.org/mailman/listinfo/rules-users
>>>>>> > >
>>>>>> >
>>>>>> > _______________________________________________
>>>>>> > rules-users mailing list
>>>>>> > rules-users at lists.jboss.org
>>>>>> > https://lists.jboss.org/mailman/listinfo/rules-users
>>>>>> >
>>>>>>
>>>>> _______________________________________________
>>>>> rules-users mailing list
>>>>> rules-users at lists.jboss.org
>>>>> https://lists.jboss.org/mailman/listinfo/rules-users
>>>>>
>>>>
>>>> _______________________________________________
>>>> rules-users mailing list
>>>> rules-users at lists.jboss.org
>>>> https://lists.jboss.org/mailman/listinfo/rules-users
>>>
>>>
>>> Felipe Piccolini M.
>>> felipe.piccolini at bluesoft.cl
>>>
>>>
>>>
>>>
>>> _______________________________________________
>>> rules-users mailing list
>>> rules-users at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/rules-users
>>>
>>
>> _______________________________________________
>> rules-users mailing list
>> rules-users at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/rules-users
>
>
> Felipe Piccolini M.
> felipe.piccolini at bluesoft.cl
>
>
>
>
> _______________________________________________
> rules-users mailing list
> rules-users at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/rules-users


Felipe Piccolini M.
felipe.piccolini at bluesoft.cl




-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/rules-users/attachments/20070629/be01a58d/attachment.html

More information about the rules-users mailing list