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.
From what you say, there seems to be a problem in the latter:
"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
--
View this message in context:
http://drools.46999.n3.nabble.com/rules-users-java-lang-NullPointerExcept...
Sent from the Drools: User forum mailing list archive at
Nabble.com.