Actually (and arguably) I think that the behavior is consistent.

In the first case, you insert a MyClass instance: base is eligible
for activation, and so is rule 1. When rule 1 fires, it inserts a String
which continues the previous propagation through rule 2. At this
point, value is still != "test" and an activation for rule 2 is created.
Now the modify: since the only @PR pattern is MyClass( data == null )
in rule "base" and you are setting the property value, the (re)propagation
is blocked. This prevents the previous activation of rule 2 from being
overwritten and cancelled, so rule 2 fires.

In the second example, things are slightly different. Rule 1 activates
as in the previous case, firing. This time, you modify m first, but since
no String is in the WM, there is nothing to (re)propagate or cancel
for rule 2. However, there is indeed a MyClass instance in the WM.
When you insert the String, the modification has already been
propagated: this time the String simply joins with the existing MyClass
and continues its propagation. The next node is a "from" which
checks the current value: it is now "test", so the alpha constraint
blocks the propagation. Rule 1 does not fire as expected, but
it has little do do with @PR.

Davide

On 01/16/2014 12:33 AM, Sonata wrote:
> Below is a test to demonstrate it, also add the @PropertyReactive property to
> MyClass()
>
> package com.sample;
>
> rule base
> when m : MyClass(data == null)
> then
> end
>
> rule "2" extends base
> when
>       String()
>       MyClass(value != "test") from m
> then
>       System.out.println("2 fired");
> end
>
> rule "1" extends base
> salience 1
> when
>       MyClass(value == null) from m
> then
>       System.out.println("1 fired");
>       insert(new String());
>       modify(m) { setValue("test") }
> end
>
> The test above should output "1 fired" and "2 fired".
> Although we have set the value to "test", rule "2" supposes to not fire, but
> it is in fact expected to fire due to the non-reactive property of CE
> "from", and the result confirms this.
>
> But if we reorder the code in rule "1" to
>
> rule "1" extends base
> salience 1
> when
>       MyClass(value == null) from m
> then
>       System.out.println("1 fired");
>       modify(m) { setValue("test") }
>       insert(new String());
> end
>
> Then you get only "1 fired", as if CE "from" is reactive again.
> This only happens when you have the @PropertyReactive property added to
> MyClass()
> Version tested are 5.5.0.Final and 5.6.0.Final
>
> Could the Drools team review this? Thank you.
>
>
>
> --
> View this message in context: 
> http://drools.46999.n3.nabble.com/Inconsistent-output-when-PropertyReactive-is-used-tp4027709.html
> Sent from the Drools: User forum mailing list archive at Nabble.com.
> _______________________________________________
> rules-users mailing list
> rules-users@lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/rules-users
>

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

Reply via email to