]
Liu Yan updated DROOLS-185:
---------------------------
5.5.0.final.regards.
--------------------------------
来自我的新浪邮箱android客户端
-------- 原始邮件 --------
发件人:Davide Sottara (JIRA)
时 间:2015年1月23日 13:01(星期五)
收件人:oscar_cqu@sina.com
主题:[JBoss JIRA] (DROOLS-185) ClassCastException at ConditionEvaluator
Davide Sottara commented on DROOLS-185
Re: ClassCastException at ConditionEvaluator
Which version are you using? This should have
been fixed in recent versions
Add Comment
This message was sent by Atlassian JIRA
(v6.3.11#6341-sha1:83c4d29)
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.