[rules-users] unexpected/spurious ClassCastException

[Davide Sottara]

Ok, so there is indeed a problem in the way the query is invoked

The input arguments are of type ContextFoodItem, while the formal
arguments of the query are FoodItem.
The compiler should do a type check (which is probably missing) and
report an error at compile time.
This throws an exception in the query body, and this is the exception I
see when I run your test case.

java.lang.RuntimeException:
com.sample.Rule_isExampleOf0Eval0Invoker at 152d453a :
java.lang.ClassCastException: com.sample.ContextFoodItem cannot be cast
to com.sample.FoodItem
    at org.drools.core.rule.EvalCondition.isAllowed(EvalCondition.java:123)
    at
org.drools.core.phreak.PhreakEvalNode.doLeftInserts(PhreakEvalNode.java:55)


Actually, the exception you reported initially was

Exception in thread "main" java.lang.ClassCastException: 
com.tastiereasier.rulez.ContextFoodItem cannot be cast to 
com.tastiereasier.domain.FoodItem
     at 
ConditionEvaluator3754d879fb5b46a3b2cfbe61326ba9f5.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 ....

but it probably happens if the second part of the query - the join with
the recursive call - is triggered.

As for the "enabled" flag, it does not prevent the evaluation of the
LHS. It only disables the actual
execution of the RHS.

Let me investigate some more
Davide



On 07/09/2014 11:49 AM, Borris wrote:
> On Wednesday 09/07/2014 14:41, Davide Sottara wrote:
>> Sorry for not being able to get back to you again earlier.
>> Yes, the rule / query you are showing makes sense - I would have asked
>> you for something similar :) It is definitely a bug in the resolution of
>> the class that defines an attribute, we could really use the reproducer
>> to fix it quickly.
>>
>> I'll check the "enabled" attribute's behavior in 6.x
>> Thanks
>> Davide
> I'll tidy up the the test case I've generated and email it to you.
>
> Just to be clear, the cast exception was caused by a mistake on my part 
> in the when part of a rule, but in a rule with an "enabled false" 
> attribute. I had done the standard thing of gradually disabling bits 
> until the error went away, but had not allowed for the exception being 
> triggered with enabled false, so had assumed (not unreasonably I argue 
> :) ) that the initially supplied rules must be the cause of the problem.
>
> At least, that's my conclusion - but the test case will let you decide 
> independently.
>
> Borris
>
> _______________________________________________
> rules-users mailing list
> rules-users at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/rules-users
>