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

Chris, 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. []s Edson 2007/7/18, Chris West <crayzfishr(a)gmail.com&gt;: > > Edson, > > 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: > > Exception in thread "main" java.lang.ClassCastException: > ascc.status.FlightOpsStatusBoard$LaunchRecoveryStatusShadowProxy > at > org.drools.base.ascc.status.AirPlanStatusBoard$SortieStatus$getState.getValue(Unknown > Source) > at org.drools.base.ClassFieldExtractor.getValue ( > ClassFieldExtractor.java:94) > at > org.drools.base.evaluators.ObjectFactory$ObjectEqualEvaluator.evaluate( > ObjectFactory.java:103) > at org.drools.rule.LiteralRestriction.isAllowed( > LiteralRestriction.java:61) > at org.drools.rule.LiteralConstraint.isAllowed( > LiteralConstraint.java:82) > at org.drools.reteoo.AlphaNode.assertObject(AlphaNode.java:122) > at > org.drools.reteoo.CompositeObjectSinkAdapter.propagateAssertObject ( > CompositeObjectSinkAdapter.java:308) > at org.drools.reteoo.ObjectTypeNode.assertObject(ObjectTypeNode.java > :168) > at org.drools.reteoo.Rete.assertObject(Rete.java:166) > at org.drools.reteoo.ReteooRuleBase.assertObject ( > ReteooRuleBase.java:190) > at org.drools.reteoo.ReteooWorkingMemory.doInsert( > ReteooWorkingMemory.java:70) > at org.drools.common.AbstractWorkingMemory.update( > AbstractWorkingMemory.java:1209) > at org.drools.common.AbstractWorkingMemory.update ( > AbstractWorkingMemory.java:1129) > at ascc.rules.AbstractRulesCoordinator.statusChanged( > AbstractRulesCoordinator.java:324) > at ascc.rules.AbstractRulesCoordinator.processSend( > AbstractRulesCoordinator.java:300) > at csf.engine.AbstractModelComponent.processSend( > AbstractModelComponent.java:213) > at csf.engine.SimulationEngine$SchedulerThread.run( > SimulationEngine.java:680) > > 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. > > Thanks, > -Chris West > > > On 7/18/07, Chris West < crayzfishr(a)gmail.com&gt; wrote: > > > > 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(a)post.com&gt; 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(a)gmail.com&gt;: > > > > > > > > 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(a)codehaus.org&gt; 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(a)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=tirell... > > > > > > [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(a)lists.jboss.org > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > https://lists.jboss.org/mailman/listinfo/rules-users > > > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > > rules-users mailing list > > > > > > rules-users(a)lists.jboss.org > > > > > > https://lists.jboss.org/mailman/listinfo/rules-users > > > > > > > > > > > > > > > > > ------------------------------ > > > > > > > > > > _______________________________________________ > > > > > rules-users mailing list > > > > > rules-users(a)lists.jboss.org > > > > > > > > > > > > > > > > > > > > > > > > > https://lists.jboss.org/mailman/listinfo/rules-users > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > rules-users mailing list > > > > > rules-users(a)lists.jboss.org > > > > > https://lists.jboss.org/mailman/listinfo/rules-users > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > rules-users mailing list > > > > rules-users(a)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(a)lists.jboss.org > > > https://lists.jboss.org/mailman/listinfo/rules-users > > > > > > > > > > _______________________________________________ > rules-users mailing list > rules-users(a)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(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/rules-users