Bug 1294048 - Wrong MvelConstraint compilation with Unicode class name and the same name property
Wrong MvelConstraint compilation with Unicode class name and the same name pr...
Product: JBoss BRMS Platform 6
Classification: JBoss
Component: BRE (Show other bugs)
Unspecified Unspecified
high Severity high
: ---
: ---
Assigned To: Mario Fusco
Marek Winkler
Depends On:
  Show dependency treegraph
Reported: 2015-12-24 04:24 EST by Toshiya Kobayashi
Modified: 2016-01-25 05:33 EST (History)
0 users

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed:
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

External Trackers
Tracker ID Priority Status Summary Last Updated
JBoss Issue Tracker DROOLS-1015 Major Closed Wrong MvelConstraint compilation with Unicode class name and the same name property 2016-02-04 02:27 EST

  None (edit)
Description Toshiya Kobayashi 2015-12-24 04:24:08 EST
Description of problem:

Platform BZ for https://issues.jboss.org/browse/DROOLS-1015

Steps to Reproduce:
1. See a test case in PR (https://github.com/droolsjbpm/drools/pull/592)

Actual results:

 p : I18nPerson( 住所 != null )

matches even if 住所 is null.

Expected results:

 p : I18nPerson( 住所 != null )

doesn't match if 住所 is null.
Comment 1 Mario Fusco 2016-01-08 02:49:31 EST
I reproduced this issue in a very easy way as it follows:

    public static class person {
        private address address;

        public Misc2Test.address getAddress() {
            return address;

        public void setAddress( Misc2Test.address address ) {
            this.address = address;

    public static class address { }

    public void testLowerCaseClass() {
        // DROOLS-1015
        String drl =
                "import " + person.class.getCanonicalName() + "\n" +
                "import " + address.class.getCanonicalName() + "\n" +
                "global java.util.List list;\n" +
                "rule R when\n" +
                "    person( address == null )\n" +
                "then\n" +
                "    list.add(\"ok\");\n" +

        KieSession ksession = new KieHelper().addContent( drl, ResourceType.DRL )

        List<String> list = new ArrayList<String>();
        ksession.setGlobal( "list", list );

        ksession.insert( new person() );

        assertEquals( 1, list.size() );

The problem here is caused by mvel class literals. In practice since 'address' is also the name of an imported class mvel interprets the constraint:

person( address == null )

as it was

person( address.class == null )

That of course always evaluates to false regardless if the person has a value in its address field or not. I'm trying to fix this problem without breaking this mvel feature by changing the precedence in which mvel disambiguate the 'address' word during parsing giving a lower priority to class literals. The problem is that at the moment all literals (like constants and even class literals) are the very first thing that are resolved by mvel during the parsing of an expression. I spent a couple of hours try to change this only for class literals, but the more I try the more I realize that achieving this result could take me many days of work.

I believe that going further with this attempt doesn't worth the effort for at least 2 good reason:

1. as you know one of the goal for drools 7 is getting rid of mvel.

2. there's an easy way to disambiguate the 'address' token. In fact replacing

person( address == null )


person( this.address == null )

will have the expected behavior.

My expectation is that the workaround I'm suggesting in 2. will also work for your use case.
This issue will be fixed in Drools 7.
Comment 2 JBoss JIRA Server 2016-01-25 05:33:20 EST
Mario Fusco <mario.fusco@gmail.com> updated the status of jira DROOLS-1015 to Closed

Note You need to log in before you can comment on or make changes to this bug.