January 2016 - jboss-jira - Jboss List Archives

[JBoss JIRA] (DROOLS-1015) Wrong MvelConstraint compilation with Unicode class name and the same name property

by Toshiya Kobayashi (JIRA)

[ https://issues.jboss.org/browse/DROOLS-1015?page=com.atlassian.jira.plugi... ] Toshiya Kobayashi updated DROOLS-1015: -------------------------------------- Workaround Description: * A. Add "this." to the property. for example, ( 住所 != null ) -> ( this.住所 != null ) or * B. Use a different property name from class name was: A. Add "this." to the property. for example, ( 住所 != null ) -> ( this.住所 != null ) or B. Use a different property name from class name > 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 > Fix For: 7.0.0.Final > > > 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)

10 years, 3 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-1015) Wrong MvelConstraint compilation with Unicode class name and the same name property

by Toshiya Kobayashi (JIRA)

[ https://issues.jboss.org/browse/DROOLS-1015?page=com.atlassian.jira.plugi... ] Toshiya Kobayashi updated DROOLS-1015: -------------------------------------- Workaround Description: A. Add "this." to the property. for example, or B. Use a different property name from class name was:Use a different property name from class name. But it's sometimes hard to follow. > 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 > Fix For: 7.0.0.Final > > > 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)

10 years, 3 months

1
0
0 / 0

[JBoss JIRA] (WFLY-5958) NPE in principal-to-group group searching

by Ondrej Lukas (JIRA)

[ https://issues.jboss.org/browse/WFLY-5958?page=com.atlassian.jira.plugin.... ] Ondrej Lukas updated WFLY-5958: ------------------------------- Affects Version/s: 10.0.0.CR5 > NPE in principal-to-group group searching > ----------------------------------------- > > Key: WFLY-5958 > URL: https://issues.jboss.org/browse/WFLY-5958 > Project: WildFly > Issue Type: Bug > Components: Domain Management, Security > Affects Versions: 10.0.0.CR5 > Reporter: Ondrej Lukas > Assignee: Brian Stansberry > Attachments: groupsearch.ldif > > > In case when ldap authorization with principal-to-group group searching is used in security realm and LDAP entry found by value of 'group-attribute' does not include attribute mentioned in 'group-name-attribute' then it causes authentication fail. It is caused by missing null check for groupNameAttr and hidden NPE thrown from [1]. > [1] https://github.com/wildfly/wildfly-core/blob/18393273a1c9e464fb0cc9597951... -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 3 months

1
0
0 / 0

[JBoss JIRA] (WFLY-5958) NPE in principal-to-group group searching

by Ondrej Lukas (JIRA)

Ondrej Lukas created WFLY-5958: ---------------------------------- Summary: NPE in principal-to-group group searching Key: WFLY-5958 URL: https://issues.jboss.org/browse/WFLY-5958 Project: WildFly Issue Type: Bug Components: Domain Management, Security Reporter: Ondrej Lukas Assignee: Brian Stansberry In case when ldap authorization with principal-to-group group searching is used in security realm and LDAP entry found by value of 'group-attribute' does not include attribute mentioned in 'group-name-attribute' then it causes authentication fail. It is caused by missing null check for groupNameAttr and hidden NPE thrown from [1]. [1] https://github.com/wildfly/wildfly-core/blob/18393273a1c9e464fb0cc9597951... -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 3 months

1
0
0 / 0

[JBoss JIRA] (WFLY-5958) NPE in principal-to-group group searching

by Ondrej Lukas (JIRA)

[ https://issues.jboss.org/browse/WFLY-5958?page=com.atlassian.jira.plugin.... ] Ondrej Lukas updated WFLY-5958: ------------------------------- Attachment: groupsearch.ldif > NPE in principal-to-group group searching > ----------------------------------------- > > Key: WFLY-5958 > URL: https://issues.jboss.org/browse/WFLY-5958 > Project: WildFly > Issue Type: Bug > Components: Domain Management, Security > Reporter: Ondrej Lukas > Assignee: Brian Stansberry > Attachments: groupsearch.ldif > > > In case when ldap authorization with principal-to-group group searching is used in security realm and LDAP entry found by value of 'group-attribute' does not include attribute mentioned in 'group-name-attribute' then it causes authentication fail. It is caused by missing null check for groupNameAttr and hidden NPE thrown from [1]. > [1] https://github.com/wildfly/wildfly-core/blob/18393273a1c9e464fb0cc9597951... -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 3 months

1
0
0 / 0

[JBoss JIRA] (JGRP-1982) RequestCorrelator: use IntHashMap / LongHashmap for request correlation

by Bela Ban (JIRA)

[ https://issues.jboss.org/browse/JGRP-1982?page=com.atlassian.jira.plugin.... ] Bela Ban commented on JGRP-1982: -------------------------------- Turns out that compaction 'in the middle' doesn't work with the current design. If we have ||0||1||2||3||4||5||6||7|| |-|-|-|-|-|21|22|23| where low=21 and high=24. Compacting this yield: ||0||1||2||3|| |-|21|22|23| (low=21, high=24) However, growing the array again yields: ||0||1||2||3||4||5||6||7|| |-|21|22|23|-|-|-|-| (low=21, high=24) The problem here is that we hash a _seqno_ to an _index_, but once we've done this, we don't know what the actual seqno is, and hash on the indices only. E.g. indices for 21,22,23 and 5,6,7, then 1,2,3. The root issue is that a mod operation (hash) is not bijective, ie. {{21 % 8 = 5}}, but we cannot compute the original seqno 21 from 5. We'd have to store the original seqno with the value, but that's too much overhead... > RequestCorrelator: use IntHashMap / LongHashmap for request correlation > ----------------------------------------------------------------------- > > Key: JGRP-1982 > URL: https://issues.jboss.org/browse/JGRP-1982 > Project: JGroups > Issue Type: Enhancement > Reporter: Bela Ban > Assignee: Bela Ban > Priority: Minor > Fix For: 3.6.7 > > > In RequestCorrelator (and possibly other classes), use an IntHashMap or LongHashmap for the request table. Goal: use less space when we have a lot of requests. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 3 months

1
0
0 / 0

[JBoss JIRA] (JGRP-2001) RequestCorrelator: request-ID is sent in request and header

by Bela Ban (JIRA)

Bela Ban created JGRP-2001: ------------------------------ Summary: RequestCorrelator: request-ID is sent in request and header Key: JGRP-2001 URL: https://issues.jboss.org/browse/JGRP-2001 Project: JGroups Issue Type: Enhancement Reporter: Bela Ban Assignee: Bela Ban Priority: Minor Fix For: 3.6.7 When invoking a sync RPC, a request is identified by a _request ID_ (req_id, a long). This is sent in both the header and the request itself, so we can remove one of them. Also, in {{Header}}, we can drop field {{rsp_expected}}: this can be replaced by setting {{req_id}} to {{-1}}. Summary: we can drop a long ({{req_id}}) field in {{Request}} and a boolean ({{rsp_expected}} in {{Header}}) from each RPC. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 3 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-1015) Wrong MvelConstraint compilation with Unicode class name and the same name property

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/DROOLS-1015?page=com.atlassian.jira.plugi... ] RH Bugzilla Integration commented on DROOLS-1015: ------------------------------------------------- Mario Fusco <mfusco(a)redhat.com> changed the Status of [bug 1294048|https://bugzilla.redhat.com/show_bug.cgi?id=1294048] from NEW to ASSIGNED > 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 > Fix For: 7.0.0.Final > > > 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)

10 years, 3 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-1015) Wrong MvelConstraint compilation with Unicode class name and the same name property

by Mario Fusco (JIRA)

[ https://issues.jboss.org/browse/DROOLS-1015?page=com.atlassian.jira.plugi... ] Mario Fusco updated DROOLS-1015: -------------------------------- Fix Version/s: 7.0.0.Final > 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 > Fix For: 7.0.0.Final > > > 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)

10 years, 3 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-1015) Wrong MvelConstraint compilation with Unicode class name and the same name property

by Mario Fusco (JIRA)

[ 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)

10 years, 3 months

1
0
0 / 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-jira January 2016