Bug 768952

Summary: Unwanted coersion of a String type
Product: [JBoss] JBoss Enterprise BRMS Platform 5 Reporter: Alessandro Lazarotti <alazarot>
Component: BRE (Expert, Fusion)Assignee: Mario Fusco <mfusco>
Status: CLOSED UPSTREAM QA Contact: Marek Baluch <mbaluch>
Severity: high Docs Contact:
Priority: unspecified    
Version: 5.0, 5.1.0 GA, BRMS 5.2.0.GACC: mproctor
Target Milestone: ---   
Target Release: BRMS 5.3.0.GA   
Hardware: Unspecified   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
When the 'in' keyword is used to evaluate a String value against a set of values in the LHS of the rule, the String is treated as a float value. This was caused by a wrong type coercion in MVEL. The issue has been resolved and String values are now treated as Strings when used with the 'in' keyword.
Story Points: ---
Clone Of: Environment:
Last Closed: 2025-02-10 03:14:34 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Attachments:
Description Flags
project test none

Description Alessandro Lazarotti 2011-12-19 14:12:55 UTC
The use of multi-restriction or the use of "in" operator causes a unwanted coersion from String types to decimal types.
For example (Message.message is String and someEntity.someString is String as well):


            Message message = new Message();
            SomeEntity someEntity = new SomeEntity();
	    someEntity.setSomeString("1.5");
            message.setSomeEntity(someEntity);
            message.setMessage("1.5");
            ksession.insert(message);
            ksession.fireAllRules();


rule "R1"
dialect "java" 
salience 2
    when
        Message($message: message in ("1.500") )
    then
        System.out.println("Result for R1 " + $message );
end


rule "R2"
dialect "java"
salience 1 
    when
      m:  Message( someEntity.someString in ("1.500") )
    then
        System.out.println("Result for R2 " + m.getSomeEntity().getSomeString() );
end


Using Drools 5.2 and Drools 5.3 you have printed:

"Result for R1 1.5
 Result for R2 1.5"

... there, was done a coercion to decimal and all conditionals returned true then the rules were fired. If used a single constraint with "==" operator instead of "in", no rule is fired (as expected).

Using Drools 5.0.x and Drools 5.1.x the result is different, only R2 is fired... so there is the same problem, but only for nested objects.
The fix should works for both cases, nested objects and for direct access for properties.

I am not sure if Multi-restriction is a MVEl feature, I think it is implemented by pure Drools parser, so I am not opening a new MVEL issue based on that. However, let me know if it is necessary.

Comment 1 Alessandro Lazarotti 2011-12-19 14:18:54 UTC
Created attachment 548593 [details]
project test

Execute CoersionTest.java and look coercion.drl

Comment 4 JBoss JIRA Server 2012-01-19 10:35:26 UTC
Mario Fusco <mario.fusco> updated the status of jira JBRULES-3302 to Resolved

Comment 5 JBoss JIRA Server 2012-01-19 10:35:26 UTC
Mario Fusco <mario.fusco> made a comment on jira JBRULES-3302

That was caused by a wrong type coersion in mvel

Comment 7 Ryan Zhang 2012-02-15 09:12:30 UTC
Please verify the issue on 5.3 ER4.

Comment 8 Jiri Svitak 2012-02-23 10:44:57 UTC
Verified in BRMS 5.3 ER4.

Comment 11 lcarlon 2012-06-01 03:33:11 UTC
    Technical note added. If any revisions are required, please edit the "Technical Notes" field
    accordingly. All revisions will be proofread by the Engineering Content Services team.
    
    New Contents:
When the 'in' keyword is used to evaluate a String value against a set of values in the LHS of the rule, the String is treated as a float value. This was caused by a wrong type coercion in MVEL. The issue has been resolved and String values are now treated as Strings when used with the 'in' keyword.

Comment 13 Red Hat Bugzilla 2025-02-10 03:14:34 UTC
This product has been discontinued or is no longer tracked in Red Hat Bugzilla.