Edson, <br><br>I'll try to re-create the problem in a self contained test, but my rules are very complex and very numerous, so I'm having a hard time pinpointed what exactly triggers the condition.<br><br>As far as my code goes, my company will not let me disclose any of it. Thanks for the suggestion, however.
<br><br>Thanks,<br>-Chris West<br><br><div><span class="gmail_quote">On 7/18/07, <b class="gmail_sendername">Edson Tirelli</b> <<a href="mailto:tirelli@post.com">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> It is probably related. Can you isolate that in a self contained test and send me? If it is proprietary code, you may send direct to me instead of the list and I will not disclose. If we can fix that today, we may be able to include it in final release as a bug fix.
<br><br> []s<br> Edson<br><br><div><span class="gmail_quote">2007/7/18, Chris West <<a href="mailto:crayzfishr@gmail.com" target="_blank" onclick="return top.js.OpenExtLink(window,event,this)">crayzfishr@gmail.com
</a>>:</span><div><span class="e" id="q_113da2ee402a4e49_1"><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
Edson,<br><br>After further investigation, I found that I was still manually setting the property "drools.shadowProxyExcludes" to exclude my proxies from being shadowed (even thought they would not have been shadowed anyway in
4.0.0MR3. After removing this property, the latest snapshot from the trunk seems to shadow my proxy based facts. However, I crash later in my code with the following exception:<br><br>Exception in thread "main"
java.lang.ClassCastException: ascc.status.FlightOpsStatusBoard$LaunchRecoveryStatusShadowProxy<br> at org.drools.base.ascc.status.AirPlanStatusBoard$SortieStatus$getState.getValue(Unknown Source)<br> at org.drools.base.ClassFieldExtractor.getValue
(ClassFieldExtractor.java:94)<br> at org.drools.base.evaluators.ObjectFactory$ObjectEqualEvaluator.evaluate(ObjectFactory.java:103)<br> at org.drools.rule.LiteralRestriction.isAllowed(LiteralRestriction.java:61)<br>
at org.drools.rule.LiteralConstraint.isAllowed(LiteralConstraint.java:82)<br> at org.drools.reteoo.AlphaNode.assertObject(AlphaNode.java:122)<br> at org.drools.reteoo.CompositeObjectSinkAdapter.propagateAssertObject
(CompositeObjectSinkAdapter.java:308)<br> at org.drools.reteoo.ObjectTypeNode.assertObject(ObjectTypeNode.java:168)<br> at org.drools.reteoo.Rete.assertObject(Rete.java:166)<br> at org.drools.reteoo.ReteooRuleBase.assertObject
(ReteooRuleBase.java:190)<br> at org.drools.reteoo.ReteooWorkingMemory.doInsert(ReteooWorkingMemory.java:70)<br> at org.drools.common.AbstractWorkingMemory.update(AbstractWorkingMemory.java:1209)<br> at org.drools.common.AbstractWorkingMemory.update
(AbstractWorkingMemory.java:1129)<br> at ascc.rules.AbstractRulesCoordinator.statusChanged(AbstractRulesCoordinator.java:324)<br> at ascc.rules.AbstractRulesCoordinator.processSend(AbstractRulesCoordinator.java:300)
<br> at csf.engine.AbstractModelComponent.processSend(AbstractModelComponent.java:213)<br> at csf.engine.SimulationEngine$SchedulerThread.run(SimulationEngine.java:680)<br><br>I see the name LaunchRecoveryStatusShadowProxy above, which indicates a cast is trying to occur that cannot. Could this be related to the change you made to shadow proxies? If not, any ideas what might be occuring? I don't have a simple test case for this problem.
<br><br>Thanks,<br><span>-Chris West</span><div><span><br><br><br><div><span class="gmail_quote">On 7/18/07, <b class="gmail_sendername">Chris West</b> <<a href="mailto:crayzfishr@gmail.com" target="_blank" onclick="return top.js.OpenExtLink(window,event,this)">
crayzfishr@gmail.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;">
Edson,<br><br>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.
<br><br>Thanks,<br><span>Chris West<br><br></span><div><span><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></span><div><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> I found and developed an intermediate solution that shall work for your proxies.<br> 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.
<br><br> 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.<br><br> Thanks,
<br><span> Edson<br><br><br></span><div><span><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></span><div><span><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
Is that still true if the equals() and hashcode() methods are only based on the identity fields of the object (which cannot change)?<div><span><br><br>-Chris West<br><br><div><span class="gmail_quote">
On 7/17/07, <b class="gmail_sendername">
Mark Proctor</b> <<a href="mailto:mproctor@codehaus.org" target="_blank" onclick="return top.js.OpenExtLink(window,event,this)">mproctor@codehaus.org</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;">
<div bgcolor="#ffffff" text="#000000">
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.<br><span>
<br>
Mark</span><div><span><br>
Chris West wrote:
<blockquote type="cite">Mark,<br>
<br>
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.<br>
<br>
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.
<br>
<br>
Is there any way to have this hidden such that I can still call
"update" but have it use "modifyRetract" and "modifyInsert" instead?<br>
<br>
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.
<br>
<br>
Thanks,<br>
-Chris West<br>
<br>
<div><span class="gmail_quote">On 7/17/07, <b class="gmail_sendername">Mark Proctor</b> <<a href="mailto:mproctor@codehaus.org" target="_blank" onclick="return top.js.OpenExtLink(window,event,this)">mproctor@codehaus.org
</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;">
<div bgcolor="#ffffff" text="#000000">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:<br>
modify ( person ) { age += 1, location = "london" }<br>
<br>
Mark<br>
Chris West wrote:
<blockquote type="cite">
<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="113da2ee402a4e49_113da2257e6df9eb_113d9ba3c6b6bfe1_113d72a2500627e6_113d603591cfc572_113d59949b2bc3ef_113d50c1fa4309e0_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>
-Chris West<br>
<br>
</span></div>
<pre><hr size="4" width="90%"><span>
_______________________________________________<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
<br><br><br><br><br><br></a>
<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>
</span></pre>
</blockquote>
<br>
</div>
<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>
<pre><hr size="4" width="90%">
_______________________________________________<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
<br><br><br><br><br></a>
<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>
</pre>
</blockquote>
<br>
</span></div></div>
<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 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></span>
</div></div>
<br><br clear="all"><div><span><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>
</span></div><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></span>
</div></div>
<br>
</blockquote></div><br>
</span></div><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></span>
</div></div><div><span class="e" id="q_113da2ee402a4e49_3">
<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>
</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>