What you write about the error message is not consistent. A "casr to String" cannot produce an error message "cannot cast primarySite to a FactHnadle". -W On 14/02/2014, mattmadhavan <mmadhavan(a)facs.org&gt; wrote:

Matt, I had answered another thread directly on the forum, I'm not sure that it made it to the user list. This was my answer: <<Unfortunately I am not completely surprised... ironically, that function signature was changed at some point to simplify the code and make it more robust internally. The change, however, broke the backwards compatibility with existing custom implementations (something the users can fix) and the way the evaluators are invoked by MVEL in the constraints. The latter required to create an EvaluatorWrapper class which is responsible for matching the Objects to their handles and extractors. "the first step return back the same factHandle object" Could you make sure that the factHandle is holding the correct object and that the extractor is a ClassFieldExtractor trying to read the appropriate field? A self-contained reproducer would also be appreciated. Some bugs related to the custom evaluators were fixed last week in 6.1 master, it would be important to know if this bug is still there, and whether the fixes should be backported and how Thank you in advance Davide I have noticed another small detail: << The error is: [Error: inlist0.evaluate( PRIMARY_SITE, ("C500-C505") ): org.drools.common.DefaultFactHandle cannot be cast to java.lang.String] [Near : {... inlist0.evaluate( PRIMARY_SITE ....}] Since PRIMARY_SITE is capitalized, is it a regular field, or something else like a global? There was a bug we found last week which may be related: https://issues.jboss.org/browse/DROOLS-426 Davide On 02/17/2014 05:25 PM, mattmadhavan wrote: