August 2017 - jboss-jira - Jboss List Archives

[JBoss JIRA] (DROOLS-1703) When incompatible varargs constructors exist, resolution sometimes incorrect

by Gerard Krupa (JIRA)

[ https://issues.jboss.org/browse/DROOLS-1703?page=com.atlassian.jira.plugi... ] Gerard Krupa edited comment on DROOLS-1703 at 8/21/17 7:32 AM: --------------------------------------------------------------- If we remove the 2nd constructor (thus removing the ambiguity), leaving constructor 3 the problem still exists, depending on the order in which the constructors are declared. I've updated the demo project to reflect this. was (Author: gjkrupa): If we remove the 2nd constructor (thus removing the ambiguity), leaving constructor 3 the problem still exists, depending on the order in which the constructors are declared. > When incompatible varargs constructors exist, resolution sometimes incorrect > ---------------------------------------------------------------------------- > > Key: DROOLS-1703 > URL: https://issues.jboss.org/browse/DROOLS-1703 > Project: Drools > Issue Type: Bug > Components: core engine > Affects Versions: 6.5.0.Final > Environment: CentOS 7 (x86_64) > openjdk version "1.8.0_131" > OpenJDK Runtime Environment (build 1.8.0_131-b12) > OpenJDK 64-Bit Server VM (build 25.131-b12, mixed mode) > Apache Maven 3.5.0 (ff8f5e7444045639af65f6095c62210b5713f426; 2017-04-03T19:39:06Z) > Reporter: Gerard Krupa > Assignee: Mario Fusco > > We have a class with 3 constructors: > Thingy(String name) > Thingy(String name, Object... args) > Thingy(String name, String version, Object... args) > When calling the constructor with a single paramater from a DRL: > Thingy(drools.getRule().getName()) > we sometimes get an odd exception in our unit tests: > {{[INFO] java.lang.StringIndexOutOfBoundsException: String index out of range: -1 > [INFO] at java.lang.String.substring(String.java:1927) > [INFO] at org.mvel2.util.ErrorUtil.rewriteIfNeeded(ErrorUtil.java:17) > [INFO] at org.mvel2.optimizers.impl.refl.ReflectiveAccessorOptimizer.getMethod(ReflectiveAccessorOptimizer.java:975) > [INFO] at org.mvel2.optimizers.impl.refl.ReflectiveAccessorOptimizer.compileGetChain(ReflectiveAccessorOptimizer.java:396) > [INFO] at org.mvel2.optimizers.impl.refl.ReflectiveAccessorOptimizer.optimizeAccessor(ReflectiveAccessorOptimizer.java:163)}} > The root cause of the issue appears to be the selection of varargs constructors by ParseTools.getBestConstructorCandidate and getMethodScore. The scoring checks that the arguments from left to right match the expected parameter classes and scores based on their coerce-ability. The scoring then compares the number of parameters to arguments *only* if the accumulated score is still 0 (and at this point it's not zero because the first parameter matched the expected type). > All 3 constructors in this list score and match the same and if the incompatible constructor is examined first then it's used. This in turn causes VarArgs.normalizeArgsForVarArgs to attempt to create an array of size -1 as it calculates the needed size of the varargs array. The reported exception seems to be generated as the exception handler itself crashes, being unable to deal with the root cause error. > https://github.com/GJKrupa/DROOLS-1703 -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 8 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-1703) When incompatible varargs constructors exist, resolution sometimes incorrect

by Gerard Krupa (JIRA)

[ https://issues.jboss.org/browse/DROOLS-1703?page=com.atlassian.jira.plugi... ] Gerard Krupa commented on DROOLS-1703: -------------------------------------- If we remove the 2nd constructor (thus removing the ambiguity), leaving constructor 3 the problem still exists, depending on the order in which the constructors are declared. > When incompatible varargs constructors exist, resolution sometimes incorrect > ---------------------------------------------------------------------------- > > Key: DROOLS-1703 > URL: https://issues.jboss.org/browse/DROOLS-1703 > Project: Drools > Issue Type: Bug > Components: core engine > Affects Versions: 6.5.0.Final > Environment: CentOS 7 (x86_64) > openjdk version "1.8.0_131" > OpenJDK Runtime Environment (build 1.8.0_131-b12) > OpenJDK 64-Bit Server VM (build 25.131-b12, mixed mode) > Apache Maven 3.5.0 (ff8f5e7444045639af65f6095c62210b5713f426; 2017-04-03T19:39:06Z) > Reporter: Gerard Krupa > Assignee: Mario Fusco > > We have a class with 3 constructors: > Thingy(String name) > Thingy(String name, Object... args) > Thingy(String name, String version, Object... args) > When calling the constructor with a single paramater from a DRL: > Thingy(drools.getRule().getName()) > we sometimes get an odd exception in our unit tests: > {{[INFO] java.lang.StringIndexOutOfBoundsException: String index out of range: -1 > [INFO] at java.lang.String.substring(String.java:1927) > [INFO] at org.mvel2.util.ErrorUtil.rewriteIfNeeded(ErrorUtil.java:17) > [INFO] at org.mvel2.optimizers.impl.refl.ReflectiveAccessorOptimizer.getMethod(ReflectiveAccessorOptimizer.java:975) > [INFO] at org.mvel2.optimizers.impl.refl.ReflectiveAccessorOptimizer.compileGetChain(ReflectiveAccessorOptimizer.java:396) > [INFO] at org.mvel2.optimizers.impl.refl.ReflectiveAccessorOptimizer.optimizeAccessor(ReflectiveAccessorOptimizer.java:163)}} > The root cause of the issue appears to be the selection of varargs constructors by ParseTools.getBestConstructorCandidate and getMethodScore. The scoring checks that the arguments from left to right match the expected parameter classes and scores based on their coerce-ability. The scoring then compares the number of parameters to arguments *only* if the accumulated score is still 0 (and at this point it's not zero because the first parameter matched the expected type). > All 3 constructors in this list score and match the same and if the incompatible constructor is examined first then it's used. This in turn causes VarArgs.normalizeArgsForVarArgs to attempt to create an array of size -1 as it calculates the needed size of the varargs array. The reported exception seems to be generated as the exception handler itself crashes, being unable to deal with the root cause error. > https://github.com/GJKrupa/DROOLS-1703 -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 8 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-1703) When incompatible varargs constructors exist, resolution sometimes incorrect

by Midhun Coumaressane (JIRA)

[ https://issues.jboss.org/browse/DROOLS-1703?page=com.atlassian.jira.plugi... ] Midhun Coumaressane edited comment on DROOLS-1703 at 8/21/17 7:25 AM: ---------------------------------------------------------------------- (1) Thingy(String name, Object... args) [shadows constructor (2)] (2) Thingy(String name, String version, Object... args) In Java world Constructor (2) should never be invoked as the signature for (1) & (2) is just the same. Should be careful when Object is used as varargs. This is not a drools bug. Just the constructor needs to be fixed irrespective of how Drool parses the rule. Either constructor (2) or (3) should be declared. Not both. was (Author: midhun18): (1) Thingy(String name, Object... args) [shadows constructor (2)] (2) Thingy(String name, String version, Object... args) In Java world Constructor (2) should never be invoked as the signature for (1) & (2) is just the same. Should be careful when Object is used as varargs. This is not a drools bug. Just the constructor needs to be fixed irrespective of how Drool parses the rule. > When incompatible varargs constructors exist, resolution sometimes incorrect > ---------------------------------------------------------------------------- > > Key: DROOLS-1703 > URL: https://issues.jboss.org/browse/DROOLS-1703 > Project: Drools > Issue Type: Bug > Components: core engine > Affects Versions: 6.5.0.Final > Environment: CentOS 7 (x86_64) > openjdk version "1.8.0_131" > OpenJDK Runtime Environment (build 1.8.0_131-b12) > OpenJDK 64-Bit Server VM (build 25.131-b12, mixed mode) > Apache Maven 3.5.0 (ff8f5e7444045639af65f6095c62210b5713f426; 2017-04-03T19:39:06Z) > Reporter: Gerard Krupa > Assignee: Mario Fusco > > We have a class with 3 constructors: > Thingy(String name) > Thingy(String name, Object... args) > Thingy(String name, String version, Object... args) > When calling the constructor with a single paramater from a DRL: > Thingy(drools.getRule().getName()) > we sometimes get an odd exception in our unit tests: > {{[INFO] java.lang.StringIndexOutOfBoundsException: String index out of range: -1 > [INFO] at java.lang.String.substring(String.java:1927) > [INFO] at org.mvel2.util.ErrorUtil.rewriteIfNeeded(ErrorUtil.java:17) > [INFO] at org.mvel2.optimizers.impl.refl.ReflectiveAccessorOptimizer.getMethod(ReflectiveAccessorOptimizer.java:975) > [INFO] at org.mvel2.optimizers.impl.refl.ReflectiveAccessorOptimizer.compileGetChain(ReflectiveAccessorOptimizer.java:396) > [INFO] at org.mvel2.optimizers.impl.refl.ReflectiveAccessorOptimizer.optimizeAccessor(ReflectiveAccessorOptimizer.java:163)}} > The root cause of the issue appears to be the selection of varargs constructors by ParseTools.getBestConstructorCandidate and getMethodScore. The scoring checks that the arguments from left to right match the expected parameter classes and scores based on their coerce-ability. The scoring then compares the number of parameters to arguments *only* if the accumulated score is still 0 (and at this point it's not zero because the first parameter matched the expected type). > All 3 constructors in this list score and match the same and if the incompatible constructor is examined first then it's used. This in turn causes VarArgs.normalizeArgsForVarArgs to attempt to create an array of size -1 as it calculates the needed size of the varargs array. The reported exception seems to be generated as the exception handler itself crashes, being unable to deal with the root cause error. > https://github.com/GJKrupa/DROOLS-1703 -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 8 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-1703) When incompatible varargs constructors exist, resolution sometimes incorrect

by Midhun Coumaressane (JIRA)

[ https://issues.jboss.org/browse/DROOLS-1703?page=com.atlassian.jira.plugi... ] Midhun Coumaressane commented on DROOLS-1703: --------------------------------------------- (1) Thingy(String name, Object... args) [shadows constructor (2)] (2) Thingy(String name, String version, Object... args) In Java world Constructor (2) should never be invoked as the signature for (1) & (2) is just the same. Should be careful when Object is used as varargs. This is not a drools bug. Just the constructor needs to be fixed irrespective of how Drool parses the rule. > When incompatible varargs constructors exist, resolution sometimes incorrect > ---------------------------------------------------------------------------- > > Key: DROOLS-1703 > URL: https://issues.jboss.org/browse/DROOLS-1703 > Project: Drools > Issue Type: Bug > Components: core engine > Affects Versions: 6.5.0.Final > Environment: CentOS 7 (x86_64) > openjdk version "1.8.0_131" > OpenJDK Runtime Environment (build 1.8.0_131-b12) > OpenJDK 64-Bit Server VM (build 25.131-b12, mixed mode) > Apache Maven 3.5.0 (ff8f5e7444045639af65f6095c62210b5713f426; 2017-04-03T19:39:06Z) > Reporter: Gerard Krupa > Assignee: Mario Fusco > > We have a class with 3 constructors: > Thingy(String name) > Thingy(String name, Object... args) > Thingy(String name, String version, Object... args) > When calling the constructor with a single paramater from a DRL: > Thingy(drools.getRule().getName()) > we sometimes get an odd exception in our unit tests: > {{[INFO] java.lang.StringIndexOutOfBoundsException: String index out of range: -1 > [INFO] at java.lang.String.substring(String.java:1927) > [INFO] at org.mvel2.util.ErrorUtil.rewriteIfNeeded(ErrorUtil.java:17) > [INFO] at org.mvel2.optimizers.impl.refl.ReflectiveAccessorOptimizer.getMethod(ReflectiveAccessorOptimizer.java:975) > [INFO] at org.mvel2.optimizers.impl.refl.ReflectiveAccessorOptimizer.compileGetChain(ReflectiveAccessorOptimizer.java:396) > [INFO] at org.mvel2.optimizers.impl.refl.ReflectiveAccessorOptimizer.optimizeAccessor(ReflectiveAccessorOptimizer.java:163)}} > The root cause of the issue appears to be the selection of varargs constructors by ParseTools.getBestConstructorCandidate and getMethodScore. The scoring checks that the arguments from left to right match the expected parameter classes and scores based on their coerce-ability. The scoring then compares the number of parameters to arguments *only* if the accumulated score is still 0 (and at this point it's not zero because the first parameter matched the expected type). > All 3 constructors in this list score and match the same and if the incompatible constructor is examined first then it's used. This in turn causes VarArgs.normalizeArgsForVarArgs to attempt to create an array of size -1 as it calculates the needed size of the varargs array. The reported exception seems to be generated as the exception handler itself crashes, being unable to deal with the root cause error. > https://github.com/GJKrupa/DROOLS-1703 -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 8 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-1692) Migrate tests in drools-persistence-jpa module from Bitronix to Narayana

by Tibor Zimányi (JIRA)

[ https://issues.jboss.org/browse/DROOLS-1692?page=com.atlassian.jira.plugi... ] Tibor Zimányi edited comment on DROOLS-1692 at 8/21/17 6:55 AM: ---------------------------------------------------------------- Blocked till https://issues.jboss.org/browse/JBPM-6309 is resolved. My feature branch is here: https://github.com/baldimir/drools/tree/DROOLS-1692 was (Author: tzimanyi): Blocked till https://issues.jboss.org/browse/JBPM-6309 is resolved. > Migrate tests in drools-persistence-jpa module from Bitronix to Narayana > ------------------------------------------------------------------------ > > Key: DROOLS-1692 > URL: https://issues.jboss.org/browse/DROOLS-1692 > Project: Drools > Issue Type: Feature Request > Components: core engine > Affects Versions: 7.1.0.Final > Reporter: Tibor Zimányi > Assignee: Tibor Zimányi > Fix For: 7.3.0.Final > > > Tests in module drools-persistence-jpa must be migrated to Narayana. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 8 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-1707) Unable to set fields for declared fact types from included kiebase after updating kcontainer in BRMS 6.4

by Mario Fusco (JIRA)

[ https://issues.jboss.org/browse/DROOLS-1707?page=com.atlassian.jira.plugi... ] Mario Fusco moved RHBPMS-4872 to DROOLS-1707: --------------------------------------------- Project: Drools (was: JBoss BPMS Platform) Key: DROOLS-1707 (was: RHBPMS-4872) Workflow: GIT Pull Request workflow (was: CDW with docs v1) Docs QE Status: NEW Component/s: core engine (was: BRE) Affects Version/s: 7.2.0.Final (was: 6.4.4.GA) QE Status: NEW > Unable to set fields for declared fact types from included kiebase after updating kcontainer in BRMS 6.4 > -------------------------------------------------------------------------------------------------------- > > Key: DROOLS-1707 > URL: https://issues.jboss.org/browse/DROOLS-1707 > Project: Drools > Issue Type: Bug > Components: core engine > Affects Versions: 7.2.0.Final > Reporter: Mario Fusco > Assignee: Mario Fusco > Priority: Critical > Labels: support > > There is a KJAR with some declared fact types in kbase "kiedeclare" which are used by a second kbase "kiemodulemodel" which contains rules. > After updating a rule in "kiemodulemodel", loading the new kjar and updating it in the kcontainer (by using updateToVersion())... it is not possible to set the fields declared on kiedeclare kbsae. The fields are returning "null" and it seems like they can not be found under Message class. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 8 months

1
0
0 / 0

[JBoss JIRA] (REMJMX-155) Release Remoting JMX 3.0.0.Final

by Darran Lofthouse (JIRA)

[ https://issues.jboss.org/browse/REMJMX-155?page=com.atlassian.jira.plugin... ] Darran Lofthouse resolved REMJMX-155. ------------------------------------- Resolution: Done > Release Remoting JMX 3.0.0.Final > -------------------------------- > > Key: REMJMX-155 > URL: https://issues.jboss.org/browse/REMJMX-155 > Project: Remoting JMX > Issue Type: Release > Reporter: Darran Lofthouse > Assignee: Darran Lofthouse > Fix For: 3.0.0.Final > > -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 8 months

1
0
0 / 0

[JBoss JIRA] (REMJMX-155) Release Remoting JMX 3.0.0.Final

by Darran Lofthouse (JIRA)

Darran Lofthouse created REMJMX-155: --------------------------------------- Summary: Release Remoting JMX 3.0.0.Final Key: REMJMX-155 URL: https://issues.jboss.org/browse/REMJMX-155 Project: Remoting JMX Issue Type: Release Reporter: Darran Lofthouse Assignee: Darran Lofthouse Fix For: 3.0.0.Final -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 8 months

1
0
0 / 0

[JBoss JIRA] (REMJMX-154) Bring dependencies to Final versions aligned with WildFly Core

by Darran Lofthouse (JIRA)

[ https://issues.jboss.org/browse/REMJMX-154?page=com.atlassian.jira.plugin... ] Darran Lofthouse resolved REMJMX-154. ------------------------------------- Resolution: Done > Bring dependencies to Final versions aligned with WildFly Core > -------------------------------------------------------------- > > Key: REMJMX-154 > URL: https://issues.jboss.org/browse/REMJMX-154 > Project: Remoting JMX > Issue Type: Task > Reporter: Brian Stansberry > Assignee: Brian Stansberry > Priority: Blocker > Fix For: 3.0.0.CR2 > > -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 8 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-1692) Migrate tests in drools-persistence-jpa module from Bitronix to Narayana

by Tibor Zimányi (JIRA)

[ https://issues.jboss.org/browse/DROOLS-1692?page=com.atlassian.jira.plugi... ] Tibor Zimányi commented on DROOLS-1692: --------------------------------------- Blocked till https://issues.jboss.org/browse/JBPM-6309 is resolved. > Migrate tests in drools-persistence-jpa module from Bitronix to Narayana > ------------------------------------------------------------------------ > > Key: DROOLS-1692 > URL: https://issues.jboss.org/browse/DROOLS-1692 > Project: Drools > Issue Type: Feature Request > Components: core engine > Affects Versions: 7.1.0.Final > Reporter: Tibor Zimányi > Assignee: Tibor Zimányi > Fix For: 7.3.0.Final > > > Tests in module drools-persistence-jpa must be migrated to Narayana. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 8 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 August 2017