you only need to use modifyRetract if the object is inserted. The reason
for this is if you change field values on your facts we will not be able
to remove them from our various internal hashmaps; thus the need to
remove first prior to any changes, then make the changes and then insert
it again. We can't allow users to just call update() as we have no idea
what the old values where, thus we cannot find the objects in our hashmaps.
Mark
Chris West wrote:
Mark,
Using modifyRetract and modifyInsert seems to fix the problem (at
least in my test case I finally created). I'll try this on my real code.
My only concern here is that it puts the burden on the rule author to
know whether things are being shadowed or not. For shadowing that is
explicitly turned off this is ok. But for implicit non-shadowing
based on a class being final, this is not at all obvious to the rule
auther.
Is there any way to have this hidden such that I can still call
"update" but have it use "modifyRetract" and "modifyInsert" instead?
Also, I'm curious why I have to call modifyRetract before I start
modifing the object, since the engine does not know about my
modifications anyway until I call update or modifyInsert? By the way,
I was unable to use the block setter approach in the rule consequence
due to not having set methods for modifying my objects.
Thanks,
-Chris West
On 7/17/07, *Mark Proctor* <[EMAIL PROTECTED]
<mailto:[EMAIL PROTECTED]>> wrote:
If you do not have shadow facts you cannot use the update()
method, it will leave the working memory corrupted. Instead you
must manage this yourself, before you change any values on the
object you must call modifyRetract() and after you hvae finished
your changes ot hte object call modifyInsert() - luckily if you
are doing this in the consequence you can use the MVEL modify
keyword combined with the block setter and it does this for you:
modify ( person ) { age += 1, location = "london" }
Mark
Chris West wrote:
Hello,
With prior versions of JBoss Rules (3.0.5) I have been using JDK
generated dynamic proxies as facts, and they have been working
fine. However, after upgrading to JBoss Rules 4.0.0MR3, I cannot
seem to get the dynamic proxies to work as facts. It seems that
even though a rule fires that changes a field on the proxy, a
second rule that should not be activated after the update still
fires.
According to the JDK javadoc documentation, dynamic proxies are
created as final. My assumption is that JBoss Rules is not
creating Shadow facts for these since they are final. After
reading the JIRA at
http://jira.jboss.com/jira/browse/JBRULES-960, I now am
questioning what the effect of not using shadow facts is on the
engine. The relevant part of that is:
"The problem is that SpringAOP is generating a proxy whose
methods equals() and hashCode() are "final". As drools must
either override these methods in the shadow proxy or not shadow
the fact at all, I'm disabling shadow proxy generation for this
use case.
It is really important to note that if you are asserting
SpringAOP proxies as facts into the working memory, you will not
be able to change any field value whose field is constrained in
rules or you may incur in a memory leak and non-deterministic
behavior by the rules engine. Unfortunately there is nothing we
can do about, since when SpringAOP makes the methods equals and
hashcode final, we can't override them anymore and as so, we
can't shadow them."
[ Show ยป <http://jira.jboss.com/jira/browse/JBRULES-960> ]
Edson Tirelli
<http://jira.jboss.com/jira/secure/ViewProfile.jspa?name=tirelli>
[02/Jul/07 03:29 PM] The problem is that SpringAOP is generating
a proxy whose methods equals() and hashCode() are "final". As
drools must either override these methods in the shadow proxy or
not shadow the fact at all, I'm disabling shadow proxy generation
for this use case. It is really important to note that if you are
asserting SpringAOP proxies as facts into the working memory, you
will not be able to change any field value whose field is
constrained in rules or you may incur in a memory leak and
non-deterministic behavior by the rules engine. Unfortunately
there is nothing we can do about, since when SpringAOP makes the
methods equals and hashcode final, we can't override them anymore
and as so, we can't shadow them.
Although I'm not using SpringAOP, I believe my facts are not
being shadowed.
Is it true that not using shadow facts may lead to
non-deterministic behavior? Prior to shadow facts, the engine
seemed to handle it. Any chance of reverting back to the old
style of truth maintenance in the case of not using shadow facts.
I apologize if I'm not on the right track here. My only test
case for my problem is the entire application right now, so I
cannot offer it for discussion. Any advice would be greatly
appreciated.
Thanks,
-Chris West
------------------------------------------------------------------------
_______________________________________________
rules-users mailing list
[email protected]
<mailto:[email protected]>
https://lists.jboss.org/mailman/listinfo/rules-users
_______________________________________________
rules-users mailing list
[email protected] <mailto:[email protected]>
https://lists.jboss.org/mailman/listinfo/rules-users
------------------------------------------------------------------------
_______________________________________________
rules-users mailing list
[email protected]
https://lists.jboss.org/mailman/listinfo/rules-users
_______________________________________________
rules-users mailing list
[email protected]
https://lists.jboss.org/mailman/listinfo/rules-users
