Chris,
By the stack trace, the problem is triggered by a rule where you are
comparing (using ==) the "state" attribute of an
AirPlanStatusBoard.SortieStatus object...
[]s
Edson
2007/7/18, Chris West <[EMAIL PROTECTED]>:
Edson,
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.
As far as my code goes, my company will not let me disclose any of it.
Thanks for the suggestion, however.
Thanks,
-Chris West
On 7/18/07, Edson Tirelli <[EMAIL PROTECTED]> wrote:
>
>
> 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 <[EMAIL PROTECTED] >:
> >
> > 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 < [EMAIL PROTECTED]> 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 < [EMAIL PROTECTED]> 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 < [EMAIL PROTECTED]>:
> > > > >
> > > > > 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 <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED] > 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@lists.jboss.org
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > > https://lists.jboss.org/mailman/listinfo/rules-users
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > > _______________________________________________
> > > > > > > rules-users mailing list
> > > > > > > rules-users@lists.jboss.org
> > > > > > > https://lists.jboss.org/mailman/listinfo/rules-users
> > > > > > >
> > > > > > >
> > > > > > ------------------------------
> > > > > >
> > > > > > _______________________________________________
> > > > > > rules-users mailing list
> > > > > > rules-users@lists.jboss.org
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > > https://lists.jboss.org/mailman/listinfo/rules-users
> > > > > >
> > > > > >
> > > > > >
> > > > > > _______________________________________________
> > > > > > rules-users mailing list
> > > > > > rules-users@lists.jboss.org
> > > > > > https://lists.jboss.org/mailman/listinfo/rules-users
> > > > > >
> > > > > >
> > > > >
> > > > > _______________________________________________
> > > > > rules-users mailing list
> > > > > rules-users@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@lists.jboss.org
> > > > https://lists.jboss.org/mailman/listinfo/rules-users
> > > >
> > > >
> > >
> >
> > _______________________________________________
> > rules-users mailing list
> > rules-users@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@lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/rules-users
>
>
_______________________________________________
rules-users mailing list
rules-users@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@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/rules-users
