]
Edson Tirelli reassigned JBRULES-2267:
--------------------------------------
Assignee: Edson Tirelli (was: Mark Proctor)
NullPointerException would be thrown during rule execution
----------------------------------------------------------
Key: JBRULES-2267
URL:
https://jira.jboss.org/jira/browse/JBRULES-2267
Project: Drools
Issue Type: Bug
Security Level: Public(Everyone can see)
Components: All
Affects Versions: 5.0.1.FINAL
Environment: Drools version: 5.0.1
JDK version: 1.5.0_6
Reporter: Freddy Andersen
Assignee: Edson Tirelli
Fix For: 5.1.0.M2
Attachments: ClassFieldAccessorStore.java, HelloWorld-1.drl, Message.java,
Message.java, SerializedPackageMergeTest.java, SerializedPackageMergeTest.java
NullPointerException would be thrown during rule execution when the following conditions
were met:
1. The org.drools.rule.Package instances should be serialized/de-serialized before being
added to the RuleBase.
2. The de-serialized package instances should be added to a RuleBase - all the packages
have the same package name.
3. At least one of the rules in the packages (not in the first package to be added to the
RulBase; it would work fine while in the
first package) should contain an IN, or NOT IN operator.
Our investigation revealed the followings:
* One of the object field, ClassFieldReader. reader which is defined as transient, was
let null when the package's were added to the RuleBase.
* It became null because the parent package has been serialized/de-serialized.
* It was not properly re-wired during the package merging when adding the package(s) to
the RuleBase.
* It only happens to the conditions/fields when IN or NOT IN was used. In other words,
when a MultiRestrictionFieldConstraint was used.
* The correct ReadAccessor was correctly set to instances of
MultiRestrictionFieldConstraint in ClassFieldAccessorStore.merge, and
the instance of ReadAccessor was propagated throw restrictions, such as
OrCompositeRestriction during rule execution. The issue is that the
leaf restrictions, such as LiteralRestriction, would only use their own ReadAccessor, not
the one passed in, when evaluating isAllowed. Since
it's own ReadAccessor was not properly re-set, meaning the field reader is null in
this case, a NullPointerException would occur.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: