This is a customer case request. Requires fixing in 5.3.1 as well.

https://bugzilla.redhat.com/show_bug.cgi?id=1040891

Fixed by https://github.com/droolsjbpm/drools/commit/384b22588

Toshiya,

Mario fixed the NPE in the engine as it should not raise a NPE no matter what, but looking at the sample test case provided, it is clear that the NPE is a symptom of a problem with the rule itself:

rule rule1
when
 $p: Person($list : addresses)
 $a: Address(street == "y") from $list
then
 $list.add( new Address("z") );
 $list.add( new Address("w") );
end

The problem with the above rule is that the consequence of the rule modifies the Person object (by adding addresses), but does not notify the engine about doing that.

It might look ok, but the working memory is stale after the execution of the rule because the engine does not know the person object changed. After serializing this stale working memory, when deserializing, the engine notices that the person object changed, and it will try to cope with the change as best as possible, but the net result for the customer application is that the deserialized session (up to date) will be different from the serialized one (stale). This will probably cause bugs in the customer application that will be hard to track down.

Please advise the customer to always call modify/update to notify the engine when a fact is changed. The above rule would require an additional constraint to prevent looping, but it is the right thing to do. There are several ways of doing that, e.g. using additional constraint:

rule rule1
when
 $p: Person($list : addresses)
 $a: Address(street == "y") from $list
 not( Address( street == "z" ) from $list )
then
 $list.add( new Address("z") );
 $list.add( new Address("w") );
 update( $p );
end

It might be possible to use property reactive feature, or no-loop, or lock-on-active instead.

Verified with BRMS 6.0.1-redhat-2