Bug 1029911 - The Type Safe check mixes Inner Classes with other classes declarations
The Type Safe check mixes Inner Classes with other classes declarations
Status: VERIFIED
Product: JBoss Enterprise BRMS Platform 5
Classification: JBoss
Component: BRE (Expert, Fusion) (Show other bugs)
BRMS 5.3.1
Unspecified Unspecified
unspecified Severity unspecified
: GA
: ---
Assigned To: Mario Fusco
Marek Winkler
:
Depends On:
Blocks: 1022758
  Show dependency treegraph
 
Reported: 2013-11-13 09:01 EST by Alessandro Lazarotti
Modified: 2014-02-13 07:21 EST (History)
3 users (show)

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


Attachments (Terms of Use)
reproducer (1.72 KB, application/zip)
2013-11-13 09:03 EST, Alessandro Lazarotti
no flags Details

  None (edit)
Description Alessandro Lazarotti 2013-11-13 09:01:40 EST
The type safe check does not understand when the import uses "*" what is the difference between a class in a package and an inner class


Given a rule with the LHS like:

import com.sample.transaction.*;
import com.sample.rules.*;


     when
         scenario:     ScenarioType( this == ScenarioType.Transaction.ADD || this == ScenarioType.Transaction.EDIT  );




The model is something like:

package com.sample.rules;

public class ScenarioType {
     public static class Transaction {
        public static final ScenarioType ADD = new ScenarioType();
        public static final ScenarioType EDIT = new ScenarioType();
     }
}


The compiler will throw the exception:

------------
Unable to Analyse Expression this == ScenarioType.Transaction.ADD ||
this == ScenarioType.Transaction.EDIT:
[Error: unable to resolve method using strict-mode:
com.sempra.module.transaction.Transaction.ADD()]
[Near : {... rioType.Transaction.ADD || this == ScenarioType.Tr ....}]
                                      ^
[Line: 17, Column: 35] : [Rule name='rule test']

------------

Looks the compiler is mixing the class Transaction from com.sample.transaction.* with the inner class ScenarioType.Transaction.
Case commented the import line for com.sample.transaction.* the rule works - case used a full qualified name in import declaration the rule work - case added the annotation @typesafe(false) for ScenarioType - if removed the OR condition the rules works - but all of should not be necessary for this rules
Comment 1 Alessandro Lazarotti 2013-11-13 09:03:54 EST
Created attachment 823461 [details]
reproducer
Comment 2 Shay Matasaro 2013-11-13 10:17:36 EST
I think that it makes sense that the compiler fails for this scenario , the java compiler would fail also, but it should also fail when not using OR.
Comment 3 Shay Matasaro 2013-11-13 10:19:20 EST
when there is a chance for confusion classes should use FQN
Comment 4 Alessandro Lazarotti 2013-11-13 10:24:00 EST
should not have confusion in the scenario reported since the rule is using:
"ScenarioType.Transaction" which is different than "Transaction" - the inner class is explicitly declared in the rule so it is a bug.
Comment 7 Shay Matasaro 2013-11-19 09:32:14 EST
When OR is specified, expression is getting evaluated using "mvel" dialect (In method org.drools.rule.builder.PatternBuilder.createAndBuildPredicate()).

If I use the "mvel" syntax for accessing static inner classes ($ instead of .), the expression compiles fine.

So if I change the expression
 scenario: ScenarioType(this == ScenarioType.Transaction.ADD || this == ScenarioType.Transaction.EDIT);

to
 scenario: ScenarioType(this == ScenarioType$Transaction.ADD || this == ScenarioType$Transaction.EDIT);
it compiles fine.
Comment 8 Mario Fusco 2013-11-22 03:28:43 EST
It was a bug of mvel. I fixed the problem there and dropped a new version (2.1.8.Final). Using this new mvel of version in drools fixed this problem.
Comment 9 Shay Matasaro 2013-12-12 09:42:50 EST
Mario, thank you , fixed verified by customer
Comment 10 Marek Winkler 2014-02-13 07:21:34 EST
Verified that mvel 2.1.8.Final is bundled with 5.3.1.BRMS-P05.

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