Bug 1029911 - The Type Safe check mixes Inner Classes with other classes declarations
Summary: The Type Safe check mixes Inner Classes with other classes declarations
Keywords:
Status: VERIFIED
Alias: None
Product: JBoss Enterprise BRMS Platform 5
Classification: JBoss
Component: BRE (Expert, Fusion)
Version: BRMS 5.3.1
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: GA
: ---
Assignee: Mario Fusco
QA Contact:
URL:
Whiteboard:
Depends On:
Blocks: 1022758
TreeView+ depends on / blocked
 
Reported: 2013-11-13 14:01 UTC by Alessandro Lazarotti
Modified: 2024-01-01 01:36 UTC (History)
1 user (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed:
Type: Bug
Embargoed:


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

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.


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