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@lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/rules-users
>
_______________________________________________
rules-users mailing list
rules-users@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/rules-users
