Re: [rules-users] unexpected/spurious ClassCastException
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@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(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/rules-users