[rules-users] unexpected/spurious ClassCastException

[Borris]

Hi,

Thanks for the response.

Version is now 6.1.0.201407061813 (snapshot from last night). Previous 
version was 6.1.0.201406070605 (snapshot from about a month ago). I was 
on a snapshot because I wanted the fix for this: 
https://github.com/droolsjbpm/droolsjbpm-tools/commit/6bc54748e

Re "relationships" - hmm, there is a bit happening.

ContextDiner is declared in Drools

declare ContextDiner
     diner: Diner @key
end

ContextFoodItem is declared in Drools and extends an empty declared type:

declare ContextRegisterable end

I presume an empty declare is legal.

declare ContextFoodItem extends ContextRegisterable
     item: FoodItem @key
     avoid: boolean @key
end

FoodItem is declared in Java and extends a small sequence of abstract 
classes. It is also abstract. The concrete version is for persistence.

DatumPreference is declared in Java and is abstract. The concrete 
version handles item peristence.

All instances of $datum are FoodItem - verified with debug print.

Anything else I can add that's useful?

Borris


On Monday 07/07/2014 22:34, Davide Sottara wrote:
> What is the relationship (extends/implements) between the classes/interfaces
> in your model - ContextFoodItem, FoodItem, ContextDiner, etc.. ?
> Could you also please specify the version of Drools you are using?
> Thanks!
> Davide
>
> On 07/07/2014 03:04 PM, Borris wrote:
>> I am getting an unexpected cast exception. The backtrace looks like
>>
>> Exception in thread "main" java.lang.ClassCastException:
>> com.tastiereasier.rulez.ContextFoodItem cannot be cast to
>> com.tastiereasier.domain.FoodItem
>>       at
>> ConditionEvaluatorb792d1e4169f4ac98945e49e1412d793.evaluate(Unknown Source)
>>       at
>> org.drools.core.rule.constraint.MvelConstraint.evaluate(MvelConstraint.java:216)
>>       at
>> org.drools.core.rule.constraint.MvelConstraint.isAllowedCachedLeft(MvelConstraint.java:185)
>>       at
>> org.drools.core.common.SingleNonIndexSkipBetaConstraints.isAllowedCachedLeft(SingleNonIndexSkipBetaConstraints.java:141)
>>       at
>> org.drools.core.phreak.PhreakJoinNode.doLeftInserts(PhreakJoinNode.java:98)
>>       at org.drools.core.phreak.PhreakJoinNode.doNode(PhreakJoinNode.java:60)
>>       at
>> org.drools.core.phreak.RuleNetworkEvaluator.switchOnDoBetaNode(RuleNetworkEvaluator.java:547)
>>       at
>> org.drools.core.phreak.RuleNetworkEvaluator.evalBetaNode(RuleNetworkEvaluator.java:533)
>>       at
>> org.drools.core.phreak.RuleNetworkEvaluator.innerEval(RuleNetworkEvaluator.java:334)
>>       at
>> org.drools.core.phreak.RuleNetworkEvaluator.evalStackEntry(RuleNetworkEvaluator.java:224)
>>       at
>> org.drools.core.phreak.RuleNetworkEvaluator.outerEval(RuleNetworkEvaluator.java:166)
>>       at
>> org.drools.core.phreak.RuleNetworkEvaluator.evaluateNetwork(RuleNetworkEvaluator.java:116)
>>       at
>> org.drools.core.phreak.RuleExecutor.reEvaluateNetwork(RuleExecutor.java:193)
>>       at
>> org.drools.core.phreak.RuleExecutor.evaluateNetworkAndFire(RuleExecutor.java:68)
>>       at
>> org.drools.core.common.DefaultAgenda.fireNextItem(DefaultAgenda.java:928)
>>       at
>> org.drools.core.common.DefaultAgenda.fireAllRules(DefaultAgenda.java:1193)
>>       at
>> org.drools.core.impl.StatefulKnowledgeSessionImpl.fireAllRules(StatefulKnowledgeSessionImpl.java:1202)
>>       at
>> org.drools.core.impl.StatefulKnowledgeSessionImpl.fireAllRules(StatefulKnowledgeSessionImpl.java:1175)
>>       at com.tastiereasier.rulez.Rulez.insertAndFire(Rulez.java:168)
>>       at com.tastiereasier.rulez.Rulez.addDinerToContext(Rulez.java:310)
>>       at com.tastiereasier.rulez.Rulez.<init>(Rulez.java:101)
>>       at com.tastiereasier.rulez.Rulez.main(Rulez.java:44)
>>
>> The rules that are triggering this are:
>>
>> rule contextDinerDislike
>>       enabled true
>>       when
>>           ContextDiner( $diner; )
>>           DatumPreference
>>           (
>>               datumPreferenceType == DatumPreference.Type.PREFERENCE,
>>               belief.factor < 0.0,
>>               $datum: datum
>>           )
>>           from $diner.getDatumPreferences()
>>       then
>>           insert( new ContextFoodItem( (FoodItem) $datum, true ) );
>> end
>>
>> rule spotNewContextDinerLike
>>       enabled true
>>       when
>>           ContextDiner( $diner; )
>>           DatumPreference
>>           (
>>               datumPreferenceType == DatumPreference.Type.PREFERENCE,
>>               belief.factor > 0.0,
>>               $datum: datum
>>           )
>>           from $diner.getDatumPreferences()
>>       then
>>           insert( new ContextFoodItem( (FoodItem) $datum, false ) );
>> end
>>
>> If I disable either rule, then the other proceeds fine and no cast
>> exception happens.
>>
>> I can't see why the cast should ever be asked for - it doesn't make sense.
>>
>> If I changed the boolean parameter in the new in the insert - so both
>> are either true or both
>> are either false, there are no cast exceptions (there must be a clue here).
>>
>> If I put a debug after the insertion, the backtrace actually happens
>> after return from the
>> insert() method - implying it's something on the agenda?
>>
>> I tried using the Audit stuff to see if it gave any clues - but I've
>> never used that before
>> and simply got a heap exhaustion from Eclipse after 1/2 hour trying to
>> ingest something like 200
>> meg of trace data - I've got a lot of data being initialised into the
>> workspace before these rules
>> get a chance to do anything.
>>
>> It's feeling remarkably like a bug to me, but I don't know how to
>> interpret the backtrace usefully,
>> so it's possible I've got something messed up elsewhere - although I've
>> disabled massive amounts
>> of rules that I can.
>>
>> I grabbed a snapshot last night and it didn't change anything. (I was on
>> a snapshot from early June to fix being able to have Drools editor
>> reference my external jars.)
>>
>> Does this look like a bug or user error? It's going to take some effort
>> to try and extract a test case
>> so I really don't want to spend the effort on that unless it looks the
>> only way.
>>
>> Sage observations most appreciated.
>>
>> Borris
>>
>>
>>
>> _______________________________________________
>> rules-users mailing list
>> rules-users at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/rules-users
>>
> _______________________________________________
> rules-users mailing list
> rules-users at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/rules-users