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

Edson Tirelli tirelli at post.com
Wed Jul 18 12:15:46 EDT 2007 

   Chris,

    For the solution to work, it is important that a superclass or interface
matches all the ObjectTypes in your rulebase that your final class (proxy)
matches... I guess that is the case with JDK proxies, isn't it?

    []s
    Edson

2007/7/18, Chris West <crayzfishr at gmail.com>:
>
> Edson,
>
> I downloaded and built the latest from the trunk of the repository.  I
> applied this new build toward my test case, and it seemed to fix the
> problem.  However, when I applied it to my real project, it still exhibits
> the problem.  If I discover more information about the problem I'll let you
> know.
>
> Thanks,
> Chris West
>
> On 7/17/07, Edson Tirelli <tirelli at post.com> wrote:
> >
> >
> >    Chris,
> >
> >    I found and developed an intermediate solution that shall work for
> > your proxies.
> >    If it is not possible to create a shadow fact for a class that is
> > asserted (because the class is final or whatever), the engine goes up in the
> > class hierarchy, looking for a class or interface for which is possible to
> > create the proxy, but that still matches all ObjectTypes available in the
> > rule base matched by the original class. The analysis is a bit complex,
> > specially because new rules with new object types can be dynamically added
> > to the rule base, but I believe the solution will work for JDK proxies and
> > the most common proxy frameworks out there, that usually don't proxy
> > multiple unrelated interfaces at once.
> >
> >    So, I ask you please to get latest snapshot from the repository and
> > try it out for your use case and report back to the list the results, since
> > seems there are a few other people using similar things.
> >
> >     Thanks,
> >         Edson
> >
> >
> > 2007/7/17, Chris West < crayzfishr at gmail.com>:
> > >
> > > 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 » <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
> > > > > 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
> > >
> > >
> >
> >
> > --
> >   Edson Tirelli
> >   Software Engineer - JBoss Rules Core Developer
> >   Office: +55 11 3529-6000
> >   Mobile: +55 11 9287-5646
> >   JBoss, a division of Red Hat @ www.jboss.com
> >
> > _______________________________________________
> > 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
>
>


-- 
  Edson Tirelli
  Software Engineer - JBoss Rules Core Developer
  Office: +55 11 3529-6000
  Mobile: +55 11 9287-5646
  JBoss, a division of Red Hat @ www.jboss.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/rules-users/attachments/20070718/f27f3c93/attachment.html

More information about the rules-users mailing list