[rules-dev] Changing a fact's hashCode causes rules not to fire

[Wolfgang Laun]

Eeek!

Assume this: A is a field of B is a field of C is a field of D is a...

Object references remain the same, in all objects; I simply modify A, and
"when you change [A] you are also changing [B], so I must notify the
engine for [B]" but that's a field of C...  D... E... and so on, until
'I' for infinity?!

*It's just a change in some fact object's hashCode that causes this problem.
*

-W



On 22 June 2011 22:37, Mark Proctor <mproctor at codehaus.org> wrote:
> As One is a field of Two. When you change One you are also changing Two,
so
> you most notify the engine for Two too.
>
> MArk
> On 22/06/2011 14:37, Wolfgang Laun wrote:
>
> To avoid misunderstandings: yes, equals() is written according to
hashCode,
> i.e., according to the usual Java conventions.
>
> If
>
>    - an object of class Two contains a member of class One, and
>    - one object Two and one object One are facts, and
>    - a rule modifies One, changing its hashCode
>
> then
>
>    another rule containing the patterns
>    $one: One()
>    $two: Two( $x: one == $one )
>
> does NOT fire (any more).
>
> If you use the constraint
>    one == $one || != $one
> the rule will fire, and you can observe that hashCode results for $one and
> $x are the same and that $one.equals( $x ) returns true.
>
> Reproduced using 5.1.1 and 5.2.x
>
> -W
>
>
>
>
> _______________________________________________
> 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/20110623/6df2a343/attachment-0001.html