[rules-users] The effect of not using shadow facts

[Ellen Zhao]

you can always override equals() and hashcode() on your fact objects.
In fact it is always encouraged to do so. If you are using eclipse,
you can even choose the interesting properties which define the
semantic identity of your fact objects and eclipse can generate the
equals() and hashcode() methods automatically for you.

Regards,
Ellen

On 7/17/07, Chris West <crayzfishr at gmail.com> wrote:
> Is that still true if the equals() and hashcode() methods are only based on
> the identity fields of the object (which cannot change)?
>
>
> -Chris West
>
> On 7/17/07, Mark Proctor <mproctor at codehaus.org> wrote:
> >
> > 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 <mproctor at codehaus.org > 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 » ]
> > > Edson 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
> > > 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
>
>


-- 
Ellen Ning Zhao
Department of Computer Science
University of Applied Science of Kaiserslautern at Zweibruecken

Tel: +49-179-7447898
homepage: http://ningning.org/