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

[Edson Tirelli]

   Chris,

   Unfortunately, that is true. Shadow facts exist to ensure the rules
engine integrity. At this point, there is no alternative to shadow facts,
because the solution we used in 3.x had too many drawbacks and did not
scaled for complex rules.

   We are trying to come up with an alternative strategy compatible with
current architecture, but it will not make 4.0 final because we are in
feature freeze for the release. It will eventually come out in a maintenance
or minor release.

   Can you present us your use case for asserting JDK proxies as facts?

   Thanks,

   []s
   Edson



2007/7/17, Chris West <crayzfishr at gmail.com>:
>
> 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
>
>


-- 
  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/20070717/6d760caa/attachment.html