[rules-users] FW: Rule runs twice without explicit call to update($fact).

[Wolfgang Laun]

"Just the place for a Snark! I have said it twice:
That alone should encourage the crew.
Just the place for a Snark! I have said it thrice:
What i tell you three times is true."
[...]
He had forty-two boxes, all carefully packed,
With his name painted clearly on each:
But, since he omitted to mention the fact,         (!)
They were all left behind on the beach.

I'm not sure whether Lewis Carroll had Drools in mind when he wrote these lines,
but the allusions are there. ;-)

That said, I'll now turn to your code which indeed achieves to
"tell it thrice": once by calling the setter in a modify, twice by
calling update,
and the third time by using the PropertyChangeSupport. Small wonder that
the engine is a little confused. Simply use just one of the three, and all will
be fine.

You should certainly do it once, or else the fact will be left changed but
forgotten on the beach...

-W


2009/11/25 Jason Smith <jsmith at infotrustgroup.com>:
> I never got an answer, any answer to this question.  I really need to know
> if PropertyChangeSupport actually works.  Is anyone out there successfully
> using it?
>
> In one case (using "modify()") I get a NPE.  In all cases, the rules run
> twice unless I explicitly call "update()".  Is anyone *not* seeing this
> behaviour?  Is anyone successfully using the PropertyChangeSupport mechanism
> without explicit calls to "update()"???
>
>
> Jason Smith
>
> ________________________________
> From: Jason Smith
> Sent: Monday, November 23, 2009 12:36 PM
> To: rules-users at lists.jboss.org
> Subject: Rule runs twice without explicit call to update($fact).
>
> My colleague has confirmed that this behavior has been around since Drools
> 4, and it continues to be a problem for Drools 5.0.1 and 5.1.0.M1, assuming
> it's a problem and not working as intended.
>
> $fact.setPath("...") implements the correct PropertyChangeSupport mechanism
> for Drools.  At least Drools is using it and responding mostly as expected.
>
> This runs once:
>
> rule
>
> "Constrain to owner or published to public"
>
> when
>
> $fact : ListFact(
>
> $path : path
>
> not matches ".*owner.*",
>
> noopResponse ==
>
> true
>
> )
>
> $model : Model()
>
> then
>
> modify($fact)
>
> {
>
> setPath($fact.getPath() +
>
> "[owner]")
>
> }
>
> update($fact);
>
> end
>
>
> This runs twice:
>
> rule
>
> "Constrain to owner or published to public"
>
> when
>
> $fact : ListFact(
>
> $path : path
>
> not matches ".*owner.*",
>
> noopResponse ==
>
> true
>
> )
>
> $model : Model()
>
> then
>
> modify($fact)
>
> {
>
> setPath($fact.getPath() + "[owner]")
>
> }
>
> end
>
>
> If I don't use modify(...) and simply change the $fact bean path property,
> the same thing occurs.  If I explicitly call update($fact), the rule runs
> once.  If I don't it runs twice.
>
> I get "/path[owner][owner]" when I actually wanted "/path[owner]", because
> it ran twice, not once.
>
> Why doe update(...) work differently from the PropertyChangeSupport
> mechanism???  Shouldn't I be able to depend on Drools to run this rule only
> one time?
>
> I am, admittedly, a bit of a noob at this, but I ran this by my local Drools
> resident expert, and he doesn't know the answer either.
>
> Thanks so much!
>
>
> Jason Smith
> Software Engineer
> InfoTrust Group, Inc.
>
> 500 Discovery Parkway, Suite 200
> Superior, CO 80027
> Office 303-627-6571
> Fax 303-666-6711
> Email jsmith at infotrustgroup.com
>
> WEB www.infotrustgroup.com
>
> This e-mail and all information included herein do not constitute a legal
> agreement accorded by INFOTRUST GROUP and its affiliates and subsidiaries.
> All legal agreements must be formulated in writing by a legal representative
> of INFOTRUST GROUP. This email and any files transmitted with it are
> confidential and intended solely for the use of the individual or entity to
> whom they are addressed.  If you have received this e-mail by mistake,
> please inform us and destroy this e-mail and any documents it might
> contain.  Please note that any views or opinions presented in this email are
> solely those of the author and do not necessarily represent those of the
> company. Finally, the recipient should check this email and any attachments
> for the presence of viruses. The company accepts no liability for any damage
> caused by any virus transmitted by this email.  Thank you for your
> cooperation.
>
> _______________________________________________
> rules-users mailing list
> rules-users at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/rules-users
>
>