[rules-dev] ClassCastException:org.drools.reteoo.AlphaNode$AlphaMemorycannot be cast to org.drools.reteoo.BetaMemory

andreas.kohn at fredhopper.com andreas.kohn at fredhopper.com
Sun Apr 19 17:27:04 EDT 2009


Hi,

> Can you first do this in DRL and make sure that works, if it doesn't then 
> let us know. If it does work, then you can hopefully figure
> out what went wrong in your code from how we construct things.

well, as I almost expected, it doesn't work with the public drl APIs either, 
failing with a similar class cast as before, and under similar conditions:
* not
* two trivial childs in the not doing nothing
* rule removed and readded.

My drl:
rule "test"
when
  not(eval(true) && eval(true))
then
  # absolutely nothing
end

Test case:
ReteooRuleBase rb = new ReteooRuleBase("dummy");
PackageBuilder pkgBuilder = new PackageBuilder();
InputStream resourceStream = getClass().getResourceAsStream("/bug.drl");
pkgBuilder.addPackageFromDrl(new InputStreamReader(resourceStream));
assertTrue("Should not have errors", pkgBuilder.getErrors().isEmpty());
// Add once ...
rb.addPackage(pkgBuilder.getPackage());
assertSession(rb); // This one works
// ... remove ...
rb.removePackage(pkgBuilder.getPackage().getName());
// and add again.
rb.addPackage(pkgBuilder.getPackage());
assertSession(rb); // This fails.


assertSession(RuleBase) simply creates a (stateful) session, and calls 
fireAllRules() on it. The code in the earlier maven project was
based on how the drools unit tests construct rules programmatically, for the 
drl version the only change needed is the eval(true) to
produce the predicate constraint.

Regards,
--
Andreas



Andreas Kohn wrote:
Hi,

I'm currently integrating drools (via the .spi.* classes, not via .drl
files etc) into our product, and found a very odd class cast exception
when producing different rules.


java.lang.ClassCastException: org.drools.reteoo.AlphaNode$AlphaMemory cannot 
be cast to org.drools.reteoo.BetaMemory
	at org.drools.reteoo.NotNode.assertLeftTuple(NotNode.java:96)
	at 
org.drools.reteoo.CompositeLeftTupleSinkAdapter.doPropagateAssertLeftTuple(CompositeLeftTupleSinkAdapter.java:145)
	at 
org.drools.reteoo.CompositeLeftTupleSinkAdapter.createAndPropagateAssertLeftTuple(CompositeLeftTupleSinkAdapter.java:57)
	at 
org.drools.reteoo.LeftInputAdapterNode.assertObject(LeftInputAdapterNode.java:142)
	at 
org.drools.reteoo.SingleObjectSinkAdapter.propagateAssertObject(SingleObjectSinkAdapter.java:42)
	at org.drools.reteoo.ObjectTypeNode.assertObject(ObjectTypeNode.java:184)
	at org.drools.reteoo.EntryPointNode.assertObject(EntryPointNode.java:146)
	at org.drools.reteoo.Rete.assertObject(Rete.java:113)
	at org.drools.reteoo.ReteooRuleBase.assertObject(ReteooRuleBase.java:218)
	at 
org.drools.reteoo.ReteooWorkingMemory$WorkingMemoryReteAssertAction.execute(ReteooWorkingMemory.java:291)
	at 
org.drools.common.AbstractWorkingMemory.executeQueuedActions(AbstractWorkingMemory.java:1475)
	at 
org.drools.common.AbstractWorkingMemory.fireAllRules(AbstractWorkingMemory.java:676)
	at 
org.drools.common.AbstractWorkingMemory.fireAllRules(AbstractWorkingMemory.java:649)
	at drools.scratch.RecyclingTest.assertSession(RecyclingTest.java:88)


Attached you'll find a maven project exhibiting the error, and from
stepping through the code pieces it looks like two nodes in the network
have the same id. The id was marked as released in the removeRule()
process.

This is against the 5.0.0.SNAPSHOT.

Am I doing something wrong? Missing anything? Or is this a real
"blocker" bug? Should I open a JIRA issue for that?

Regards,
--
Andreas




_______________________________________________
rules-dev mailing list
rules-dev at lists.jboss.org
https://lists.jboss.org/mailman/listinfo/rules-dev






_______________________________________________
rules-dev mailing list
rules-dev at lists.jboss.org
https://lists.jboss.org/mailman/listinfo/rules-dev 




More information about the rules-dev mailing list