[jboss-jira] [JBoss JIRA] (DROOLS-185) ClassCastException at ConditionEvaluator

Davide Sottara (JIRA) issues at jboss.org
Wed Jan 21 04:58:49 EST 2015


    [ https://issues.jboss.org/browse/DROOLS-185?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13034036#comment-13034036 ] 

Davide Sottara commented on DROOLS-185:
---------------------------------------

This issue is very general and can manifest in a variety of cases. Drools should obey the laws of Java when it comes to implicit casting.
Notice that, for example, in Java Long and Integer are incompatible classes (unlike the primitives long and int) and Drools should not change that.

If you have reproducers where the java conventions are violated, please post them.  It is unlikely that they will be fixed in 5.6, but newer 
versions will provide the correct behavior.
Thanks
Davide

explicit casts / transformations / wrappings / changes in the data models are usually required workarounds

> ClassCastException at ConditionEvaluator
> ----------------------------------------
>
>                 Key: DROOLS-185
>                 URL: https://issues.jboss.org/browse/DROOLS-185
>             Project: Drools
>          Issue Type: Bug
>    Affects Versions: 5.5.0.Final
>            Reporter: Sergey Alaev
>            Assignee: Mario Fusco
>
> Stacktrace:
> Caused by: java.lang.ClassCastException: ***** cannot be cast to ******
> 	at ConditionEvaluator443abf2927ca4f64a4ad86407ae34799.evaluate(Unknown Source)
> 	at org.drools.rule.constraint.MvelConstraint.evaluate(MvelConstraint.java:200)
> 	at org.drools.rule.constraint.MvelConstraint.isAllowed(MvelConstraint.java:157)
> 	at org.drools.reteoo.FromNode.checkConstraintsAndPropagate(FromNode.java:318)
> 	at org.drools.reteoo.FromNode.assertLeftTuple(FromNode.java:164)
> 	at org.drools.reteoo.CompositeLeftTupleSinkAdapter.doPropagateAssertLeftTuple(CompositeLeftTupleSinkAdapter.java:232)
> 	at org.drools.reteoo.CompositeLeftTupleSinkAdapter.createAndPropagateAssertLeftTuple(CompositeLeftTupleSinkAdapter.java:116)
> 	at org.drools.reteoo.LeftInputAdapterNode.assertObject(LeftInputAdapterNode.java:154)
> 	at org.drools.reteoo.SingleObjectSinkAdapter.propagateAssertObject(SingleObjectSinkAdapter.java:59)
> Reason:
> ConditionEvaluator seems to be using lazy initializing and then caches generated class to evaluate this expression with another arguments.
> Given following:
> interface A {
>    String getString();
> }
> interface B {
>    String getString();
> }
> class X implements B, A {}
> class Y implements A{}
> rule "test rule"
> when:
>      A(string != null)
> then:
> end
> When rule engine is called for the first time with instance of class X, ConditionEvaluator will bind itself to first found interface implementing method getString(), i.e. interface B.
> Thus second call with instance of class Y will cause ClassCastException of casting Y to B.
> Solution: force MVEL to bind bytecode generated methods to class/interface declared in the rule explicitly, in our case - to interface A.
> Quickfix: use following declaration of class X:
> class X implements A, B {}
> Because ConditionEvaluator binds to first available interface, it will bind now to correct interface - to interface A.



--
This message was sent by Atlassian JIRA
(v6.3.11#6341)


More information about the jboss-jira mailing list