[
https://issues.jboss.org/browse/DROOLS-1015?page=com.atlassian.jira.plugi...
]
Mario Fusco commented on DROOLS-1015:
-------------------------------------
I reproduced this issue in a very easy way as it follows:
{code}
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 { }
@Test
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" +
"end\n";
KieSession ksession = new KieHelper().addContent( drl, ResourceType.DRL )
.build()
.newKieSession();
List<String> list = new ArrayList<String>();
ksession.setGlobal( "list", list );
ksession.insert( new person() );
ksession.fireAllRules();
assertEquals( 1, list.size() );
}
{code}
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 )
with
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.
Wrong MvelConstraint compilation with Unicode class name and the same
name property
-----------------------------------------------------------------------------------
Key: DROOLS-1015
URL:
https://issues.jboss.org/browse/DROOLS-1015
Project: Drools
Issue Type: Bug
Components: core engine
Affects Versions: 6.3.0.Final
Reporter: Toshiya Kobayashi
Assignee: Mario Fusco
If a fact has a property of Unicode class name (e.g. 住所) and the property name is the
same (住所), constraint is not correctly compiled by MVEL. Internally,
AbstractParser.createPropertyToken() misunderstands the property as a class name literal.
{code:java}
public class I18nPerson implements Serializable {
private 住所 住所; // "address" in Japanese
public 住所 get住所() {
return 住所;
}
....
{code}
{noformat}
when
p : I18nPerson( 住所 != null )
{noformat}
This constraint is always evaluated to "true".
Essentially, this is not only a problem of Unicode. We can reproduce the issue by a
capitalized property name.
{code:java}
public class Person implements Serializable {
private Address address;
public Address getAddress() {
return address;
}
....
{code}
{noformat}
when
p : I18nPerson( Address != null )
{noformat}
Of course we should use lower case letters here from JavaBeans point of view so we
don't hit this issue with English usually. But some languages like Japanese cannot
express "lower case/upper case" so result in this issue.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)