Bug 724231 (BRMS-175)

Summary: MVEL consequences + modify call == NPE
Product: [JBoss] JBoss Enterprise BRMS Platform 5 Reporter: nwallace <nwallace>
Component: unspecifiedAssignee: Edson Tirelli <ed.tirelli>
Status: CLOSED NEXTRELEASE QA Contact:
Severity: unspecified Docs Contact:
Priority: high    
Version: unspecified   
Target Milestone: ---   
Target Release: 5.0.1   
Hardware: Unspecified   
OS: Unspecified   
URL: http://jira.jboss.org/jira/browse/BRMS-175
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2009-09-01 12:26:37 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:

Description nwallace 2009-07-07 14:58:50 UTC
Date of First Response: 2009-09-10 01:23:51
securitylevel_name: Public

PetStore example is raising NPE because of a rule with MVEL dialect that contains a modify() call in the consequence.

Comment 1 nwallace 2009-07-07 15:05:19 UTC
Link: Added: This issue is related to JBRULES-2068


Comment 2 nwallace 2009-09-01 12:26:37 UTC
Fix in place.

Comment 3 David Le Sage 2009-09-10 05:23:51 UTC
For documenting this in the Release Notes, can you please confirm the following and fill in the missing information. Dot point explanations are fine:

The CAUSE (what was actually broken)
 * a modify() call on MVEL consequences

CONSEQUENCES of the bug (how it impacts users.)
 * The "Pet Store" example was failing due to a null-pointer error

The FIX (what was changed to eliminate this bug) and 
 *

RESULTS of the fix (what now happens for users.)
 * 

Comment 4 David Le Sage 2009-09-23 05:38:55 UTC
We are still awaiting the outstanding information for the Release Notes on this one.  Please provide it as soon as possible. Thanks.

Comment 5 Edson Tirelli 2009-09-23 14:06:12 UTC
The CAUSE (what was actually broken)
 * Varible values were not cached in MVEL during consequence execution, but resolved on-the-fly. This means that a modify() or retract() call on a fact would prevent any variable from being resolved from that point on in consequences. Also, modify() causes the engine to temporarily retract a fact, and so a modify block would always cause a NPE.

CONSEQUENCES of the bug (how it impacts users.)
 * The "Pet Store" example was failing due to a null-pointer error. That would also happen on any application using mvel consequences and calling modify() on the consequence.

The FIX (what was changed to eliminate this bug) and
 * DroolsMVELFactory is now caching variable values before executing code blocks like the consequence. That is similar behavior to what Java code blocks do by default.

RESULTS of the fix (what now happens for users.)
 * No more NPE on the described cases.

Comment 6 Dana Mison 2009-09-24 04:57:12 UTC
Added to 5.0 CP01 as resolved:

JBRULES-2068
Null-pointer exceptions where being thrown by MVEL rules that called modify() or retract() on a fact.
This was caused by MVEL not caching variable values during consequence execution.
DroolsMVELFactory now caches variable values before the execution of code blocks, like the consequence,
and this error no longer occurs.