Bug 1029911

Summary: The Type Safe check mixes Inner Classes with other classes declarations
Product: [JBoss] JBoss Enterprise BRMS Platform 5 Reporter: Alessandro Lazarotti <alazarot>
Component: BRE (Expert, Fusion)Assignee: Mario Fusco <mfusco>
Status: VERIFIED --- QA Contact: Marek Winkler <mwinkler>
Severity: unspecified Docs Contact:
Priority: unspecified    
Version: BRMS 5.3.1CC: nwallace
Target Milestone: GA   
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
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: --- Target Upstream Version:
Bug Depends On:    
Bug Blocks: 1022758    
Attachments:
Description Flags
reproducer none

Description Alessandro Lazarotti 2013-11-13 14:01:40 UTC
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 14:03:54 UTC
Created attachment 823461 [details]
reproducer

Comment 2 Shay Matasaro 2013-11-13 15:17:36 UTC
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 15:19:20 UTC
when there is a chance for confusion classes should use FQN

Comment 4 Alessandro Lazarotti 2013-11-13 15:24:00 UTC
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 14:32:14 UTC
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 08:28:43 UTC
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 14:42:50 UTC
Mario, thank you , fixed verified by customer

Comment 10 Marek Winkler 2014-02-13 12:21:34 UTC
Verified that mvel 2.1.8.Final is bundled with 5.3.1.BRMS-P05.