12:57 p.m.
JIRA-749 relates to NPE's in
"org.drools.reteoo.RuleTerminalNode.retractTuple".
Whether this is related....
________________________________
From: rules-users-bounces(a)lists.jboss.org
[mailto:rules-users-bounces@lists.jboss.org] On Behalf Of Chris West
Sent: 25 April 2007 14:25
To: Rules Users List
Subject: Re: [rules-users] NPE on retract
I'll try to create a self contained test. It may be a difficult
task. The error seems to come and go depending on which other rules I
leave in my rule set. In particular, there is another rule that has
many conditions and only logs a message as the consequence that when it
is included in the rule set, this error occurs. That particular rule
has nothing to do with the type of object being retracted.
My misunderstanding was that Drools used object identity with an
IdentifyHashMap unless it was configured to use a regular HashMap. Is
this not the case?
Concerning not having equals/hashcode changing while the object
is asserted into working memory, is it ok for them to change as long as
it is followed by a "modify("? Is there different behavior between
calling "modify" and calling "retract and re-assert"?
Thanks for you help,
-Chris
On 4/24/07, Edson Tirelli <tirelli(a)post.com> wrote:
Chris
Can you provide a self contained test that shows the
problem and open a JIRA with it?
I will take a look in it.
There is no requirement to define equals/hashcode,
but if you do so, you need to make them time consistent, i.e., they
cannot change during the time the object is asserted into the working
memory or you may have problems (as hashcode and equals behaviors are
defined as kind of "identity" of the object).
[]s
Edson
2007/4/24, Chris West <crayzfishr(a)gmail.com>:
Mark,
The object being retracted currently has no
hashcode and equals, therefore defaulting to the ones on Object. The
reason I'm even retracting the object is so that I can assert it again
to work around bug http://jira.jboss.com/jira/browse/JBRULES-614.
Therefore the reason I am retracting the object is because it has
changed.
Is there a requirement to implement hashcode and
equals? If so, does it have to be based on all fields of the pojo? My
intent was to implement hashcode and equals, but only base them on the
id fields of the class.
-Chris
On 4/24/07, Mark Proctor < mproctor(a)codehaus.org
<mailto:mproctor@codehaus.org> > wrote:
Have you correctly implemented your
equals and hashcode? Have you made sure that the objects fields haven't
changed between the assert and the retract?
Mark
Chris West wrote:
Hi,
Using version 3.0.6 of jboss rules,
while retracting an object, I get the following:
java.lang.NullPointerException
at
org.drools.reteoo.beta.InstanceEqualConstrRightMemory.remove(Unknown
Source)
at
org.drools.reteoo.BetaMemory.remove (Unknown Source)
at
org.drools.reteoo.NotNode.retractObject(Unknown Source)
at
org.drools.reteoo.ObjectSource.propagateRetractObject(Unknown Source)
at
org.drools.reteoo.RightInputAdapterNode.retractTuple (Unknown Source)
at
org.drools.reteoo.TupleSource.propagateRetractTuple(Unknown Source)
at
org.drools.reteoo.NotNode.retractTuple(Unknown Source)
at
org.drools.reteoo.TupleSource.propagateRetractTuple (Unknown Source)
at
org.drools.reteoo.JoinNode.retractObject(Unknown Source)
at
org.drools.reteoo.ObjectSource.propagateRetractObject(Unknown Source)
at
org.drools.reteoo.ObjectTypeNode.retractObject (Unknown Source)
at
org.drools.reteoo.Rete.retractObject(Unknown Source)
at
org.drools.reteoo.ReteooRuleBase.retractObject(Unknown Source)
at
org.drools.reteoo.ReteooWorkingMemory.doRetract(Unknown Source)
at
org.drools.common.AbstractWorkingMemory.retractObject(Unknown Source)
at
org.drools.common.AbstractWorkingMemory.retractObject(Unknown Source)
at
ascc.rules.AbstractRulesCoordinator.statusChanged(AbstractRulesCoordinat
or.java :354)
at
ascc.rules.AbstractRulesCoordinator$1.statusChanged(AbstractRulesCoordin
ator.java:111)
at
ascc.status.BaseStatusBoard.notifyChange(BaseStatusBoard.java:211)
at
ascc.status.BaseStatusBoard.notifyChange (BaseStatusBoard.java:191)
at
ascc.status.DefaultParkingStatusBoard.empty(DefaultParkingStatusBoard.ja
va:318)
at
ascc.spotting.DefaultSpottingCoordinator.computeInitialSpot(DefaultSpott
ingCoordinator.java:578)
at
ascc.spotting.DefaultSpottingCoordinator.statusCreated(DefaultSpottingCo
ordinator.java:827)
at
ascc.status.BaseStatusBoard.notifyCreate(BaseStatusBoard.java:100)
at
ascc.status.BaseStatusBoard.notifyCreate (BaseStatusBoard.java:80)
at
ascc.status.DefaultAirPlanStatusBoard.missionAssignmentComplete(DefaultA
irPlanStatusBoard.java:479)
at
ascc.missionassignment.Rule_6___Complete_mission_assignment_for_event_0.
consequence (Rule_6___Complete_mission_assignment_for_event_0.java:36)
at
ascc.missionassignment.Rule_6___Complete_mission_assignment_for_event_0C
onsequenceInvoker.evaluate(Rule_6___Complete_mission_assignment_for_even
t_0ConsequenceInvoker.java:24)
... 7 more
Is there something I could be doing
wrong? Is this a known bug?
Thanks,
-Chris
________________________________
_______________________________________________
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