<br> Chris,<br><br> I'm not sure I understood your scenario bellow, but it does seem exactly what shadow facts do: a lazy proxy.<br> In other words, lets say you have an object X. You assert X into working memory and the engine creates a shadow proxy for it. Then, you can mess with it as much as you want from outside the engine, changing its property values and etc... all that will be "invisible" to the engine, until you call an update on X. At this point, the engine will start seeing the current "snapshot" of the object properties...
<br><br> So, my question, isn't that what you are doing with your own proxy?<br><br> []s<br> Edson<br><br><div><span class="gmail_quote">2007/7/17, Chris West <<a href="mailto:crayzfishr@gmail.com">crayzfishr@gmail.com
</a>>:</span><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">Thank you for your response to this issue.<br><br>My use case for using proxies is this:
<br><br>The facts are not modifiable directly (no setter methods) or synchronously. Modifications to facts occur by calling another method which modifies the fact and notifies the rules engine of the modification asynchronously outside of the call stack (but in the same thread) that triggered the change to begin with. To give the appearance of a modification until the real notification comes asynchronously, I wrap these objects with proxies, and the proxy provides the ability to "override" a property until the real notification comes in later in a different call stack. The reason for the modifications occurring in this fashion is driven by the fact that this is a discrete event simulation, and changes to the system occur only as events which are queued to execute in priority order. The modifications to facts are just queued events just like everything else.
<br><span class="sg"><br>-Chris </span><div><span class="e" id="q_113d523e7c828823_2"><br><br><div><span class="gmail_quote">On 7/17/07, <b class="gmail_sendername">Edson Tirelli</b> <<a href="mailto:tirelli@post.com" target="_blank" onclick="return top.js.OpenExtLink(window,event,this)">
tirelli@post.com</a>> wrote:</span><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<br> Chris,<br><br> 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.
<br><br> 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.
<br><br> Can you present us your use case for asserting JDK proxies as facts?<br><br> Thanks,<br><br> []s<br> Edson<br><br> <br><br><div><span class="gmail_quote">2007/7/17, Chris West <<a href="mailto:crayzfishr@gmail.com" target="_blank" onclick="return top.js.OpenExtLink(window,event,this)">
crayzfishr@gmail.com</a>>:</span><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><div><span>Hello,<br>
<br>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.
<br><br>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 <a href="http://jira.jboss.com/jira/browse/JBRULES-960" target="_blank" onclick="return top.js.OpenExtLink(window,event,this)">
http://jira.jboss.com/jira/browse/JBRULES-960</a>, I now am questioning what the effect of not using shadow facts is on the engine. The relevant part of that is:<br><br>"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.
<br><div>
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."<br>
</div>
<div>
<div style="background: rgb(240, 240, 240) none repeat scroll 0% 50%; -moz-background-clip: -moz-initial; -moz-background-origin: -moz-initial; -moz-background-inline-policy: -moz-initial;">
<div>
[ <a href="http://jira.jboss.com/jira/browse/JBRULES-960" target="_blank" onclick="return top.js.OpenExtLink(window,event,this)">Show »</a> ]
</div>
<div style="overflow: hidden;">
<a name="113d523e7c828823_113d508e08cdd121_113d4f63da2d6c02_action_12367491">
</a><a href="http://jira.jboss.com/jira/secure/ViewProfile.jspa?name=tirelli" target="_blank" onclick="return top.js.OpenExtLink(window,event,this)">Edson Tirelli</a> <font size="-2">[<span>02/Jul/07 03:29 PM
</span>]</font>
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. </div>
</div>
</div>
<br>Although I'm not using SpringAOP, I believe my facts are not being shadowed. <br><br>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.
<br><br>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.<br><br>Thanks,
<br><span>-Chris West<br><br>
</span><br></span></div>_______________________________________________<br>rules-users mailing list<br><a href="mailto:rules-users@lists.jboss.org" target="_blank" onclick="return top.js.OpenExtLink(window,event,this)">rules-users@lists.jboss.org
</a>
<br><a href="https://lists.jboss.org/mailman/listinfo/rules-users" target="_blank" onclick="return top.js.OpenExtLink(window,event,this)">https://lists.jboss.org/mailman/listinfo/rules-users</a><br><br></blockquote></div>
<br><br clear="all"><br>-- <br> Edson Tirelli<br> Software Engineer - JBoss Rules Core Developer<br> Office: +55 11 3529-6000<br> Mobile: +55 11 9287-5646<br> JBoss, a division of Red Hat @ <a href="http://www.jboss.com" target="_blank" onclick="return top.js.OpenExtLink(window,event,this)">
www.jboss.com</a>
<br>_______________________________________________<br>rules-users mailing list<br><a href="mailto:rules-users@lists.jboss.org" target="_blank" onclick="return top.js.OpenExtLink(window,event,this)">rules-users@lists.jboss.org
</a><br><a href="https://lists.jboss.org/mailman/listinfo/rules-users" target="_blank" onclick="return top.js.OpenExtLink(window,event,this)">
https://lists.jboss.org/mailman/listinfo/rules-users</a><br><br></blockquote></div><br>
</span></div><br>_______________________________________________<br>rules-users mailing list<br><a onclick="return top.js.OpenExtLink(window,event,this)" href="mailto:rules-users@lists.jboss.org">rules-users@lists.jboss.org
</a><br><a onclick="return top.js.OpenExtLink(window,event,this)" href="https://lists.jboss.org/mailman/listinfo/rules-users" target="_blank">https://lists.jboss.org/mailman/listinfo/rules-users</a><br><br></blockquote></div>
<br><br clear="all"><br>-- <br> Edson Tirelli<br> Software Engineer - JBoss Rules Core Developer<br> Office: +55 11 3529-6000<br> Mobile: +55 11 9287-5646<br> JBoss, a division of Red Hat @ <a href="http://www.jboss.com">
www.jboss.com</a>