August 2017 - jboss-jira - Jboss List Archives

[JBoss JIRA] (DROOLS-1651) FEEL String marshaller fails on list of null

by Kris Verlaenen (JIRA)

[ https://issues.jboss.org/browse/DROOLS-1651?page=com.atlassian.jira.plugi... ] Kris Verlaenen updated DROOLS-1651: ----------------------------------- Sprint: 2017 Week 28-29, 2017 Week 30-31, 2017 Week 32-33, 2017 Week 34-35 (was: 2017 Week 28-29, 2017 Week 30-31, 2017 Week 32-33) > FEEL String marshaller fails on list of null > -------------------------------------------- > > Key: DROOLS-1651 > URL: https://issues.jboss.org/browse/DROOLS-1651 > Project: Drools > Issue Type: Bug > Components: dmn engine > Reporter: Mélanie Gauthier > Assignee: Edson Tirelli > Attachments: Invalid function.dmn > > > For example, if you execute the invalid attached file (kind attribute of the function isn't right - it is set to undefined) it produces an array of null. > When calling FEELStringMarshaller.INSTANCE.marshall(decisionResult.getResult()) you get a NPE. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 8 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-1597) Implement profile for integration with Signavio's DMN modeler

by Kris Verlaenen (JIRA)

[ https://issues.jboss.org/browse/DROOLS-1597?page=com.atlassian.jira.plugi... ] Kris Verlaenen updated DROOLS-1597: ----------------------------------- Sprint: 2017 Week 24-25, 2017 Week 26-27, 2017 Week 28-29, 2017 Week 30-31, 2017 Week 32-33, 2017 Week 34-35 (was: 2017 Week 24-25, 2017 Week 26-27, 2017 Week 28-29, 2017 Week 30-31, 2017 Week 32-33) > Implement profile for integration with Signavio's DMN modeler > ------------------------------------------------------------- > > Key: DROOLS-1597 > URL: https://issues.jboss.org/browse/DROOLS-1597 > Project: Drools > Issue Type: Enhancement > Components: dmn engine > Affects Versions: 7.1.0.Beta2 > Reporter: Edson Tirelli > Assignee: Edson Tirelli > Fix For: 7.3.0.Final > > > Signavio implements a number of extensions to the DMN standard. As they are a Red Hat partner, we will need to implement a profile in the runtime engine that enables and supports those extensions. > A short list of extensions is as follows. Details will be added to individual tickets: > * Support additional FEEL functions and alternate names for existing functions > * Support the Multi Instance Decision node > * Support character '?' for interpolation of values in a DT cell > * Support constraints on List inputs in DT cells > * Support model composition through BKMs -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 8 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-1609) Augment FEEL AST node at compilation with return type

by Kris Verlaenen (JIRA)

[ https://issues.jboss.org/browse/DROOLS-1609?page=com.atlassian.jira.plugi... ] Kris Verlaenen updated DROOLS-1609: ----------------------------------- Sprint: 2017 Week 24-25, 2017 Week 26-27, 2017 Week 28-29, 2017 Week 30-31, 2017 Week 32-33, 2017 Week 34-35 (was: 2017 Week 24-25, 2017 Week 26-27, 2017 Week 28-29, 2017 Week 30-31, 2017 Week 32-33) > Augment FEEL AST node at compilation with return type > ----------------------------------------------------- > > Key: DROOLS-1609 > URL: https://issues.jboss.org/browse/DROOLS-1609 > Project: Drools > Issue Type: Enhancement > Components: dmn engine > Reporter: Matteo Mortari > Assignee: Matteo Mortari > Priority: Minor > > This is needed so to be able to determine the result of a boxed function at compile time, in turn to be able at compile time to determine a valid compilation without error of a BKM for instance. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 8 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-1667) FEEL expression fails: 1 + if true then 1 else 2

by Kris Verlaenen (JIRA)

[ https://issues.jboss.org/browse/DROOLS-1667?page=com.atlassian.jira.plugi... ] Kris Verlaenen updated DROOLS-1667: ----------------------------------- Sprint: 2017 Week 30-31, 2017 Week 32-33, 2017 Week 34-35 (was: 2017 Week 30-31, 2017 Week 32-33) > FEEL expression fails: 1 + if true then 1 else 2 > ------------------------------------------------ > > Key: DROOLS-1667 > URL: https://issues.jboss.org/browse/DROOLS-1667 > Project: Drools > Issue Type: Bug > Components: dmn engine > Affects Versions: 7.1.0.Final > Reporter: Edson Tirelli > Assignee: Edson Tirelli > Fix For: 7.3.0.Final > > > The following FEEL expression fails to parse: > 1 + if true then 1 else 2 > Similar expressions might present the same problem. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 8 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-1553) Write documentation for the DMN and FEEL components

by Kris Verlaenen (JIRA)

[ https://issues.jboss.org/browse/DROOLS-1553?page=com.atlassian.jira.plugi... ] Kris Verlaenen updated DROOLS-1553: ----------------------------------- Sprint: 2017 Week 22-23, 2017 Week 24-25, 2017 Week 26-27, 2017 Week 28-29, 2017 Week 30-31, 2017 Week 32-33, 2017 Week 34-35 (was: 2017 Week 22-23, 2017 Week 24-25, 2017 Week 26-27, 2017 Week 28-29, 2017 Week 30-31, 2017 Week 32-33) > Write documentation for the DMN and FEEL components > --------------------------------------------------- > > Key: DROOLS-1553 > URL: https://issues.jboss.org/browse/DROOLS-1553 > Project: Drools > Issue Type: Task > Components: dmn engine > Affects Versions: 7.0.0.CR3 > Reporter: Edson Tirelli > Assignee: Edson Tirelli > Fix For: 7.3.0.Final > > > Write the documentation for both FEEL and DMN engines. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 8 months

1
0
0 / 0

[JBoss JIRA] (WFLY-9035) TransactionAttribute annotation is inherited from interface which not according to the spec

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/WFLY-9035?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on WFLY-9035: ----------------------------------------------- Radovan STANCEL <rstancel(a)redhat.com> changed the Status of [bug 1466909|https://bugzilla.redhat.com/show_bug.cgi?id=1466909] from ASSIGNED to POST > TransactionAttribute annotation is inherited from interface which not according to the spec > ------------------------------------------------------------------------------------------- > > Key: WFLY-9035 > URL: https://issues.jboss.org/browse/WFLY-9035 > Project: WildFly > Issue Type: Bug > Components: EJB > Affects Versions: 10.1.0.Final, 11.0.0.Alpha1 > Reporter: Wolf-Dieter Fink > Assignee: Radovan Stancel > Labels: transaction > > The annotation @TransactionAttribute is inherited from the business interface which is not according to the EJB specification. > Any annotation on the bean's implemenation class or deployment descriptor is overridden if the Interface is annotated with @TransactionAttribute > The EJB 3.2 specification chapter 8.3.7 says > "For a session bean written to the EJB 3.x client view API, the transaction attributes are speci- > fied for those methods of the session bean class that correspond to the bean’s business inter- > face" > Also the Javadoc for TransactionAttribute (http://docs.oracle.com/javaee/7/api/javax/ejb/TransactionAttribute.html) mention the bean class only. -- 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 updated DROOLS-1707: -------------------------------- Fix Version/s: 7.3.0.Final Sprint: 2017 Week 32-33 > 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 > Fix For: 7.3.0.Final > > > 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] (DROOLS-1707) Unable to set fields for declared fact types from included kiebase after updating kcontainer in BRMS 6.4

by Lionel Gotti (JIRA)

[ https://issues.jboss.org/browse/DROOLS-1707?page=com.atlassian.jira.plugi... ] Lionel Gotti commented on DROOLS-1707: -------------------------------------- Hi [~mfusco], thanks for the quick pull request! Can the problem be fixed on 6.4 and 6.5 branches as well? Thanks > 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] (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:38 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. We're certainly getting the develop who wrote this to do it in a more sensible way but I believe there is a Drools issue here as well. 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. I've updated the demo project to reflect this. > 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 edited comment on DROOLS-1703 at 8/21/17 7:38 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. We're certainly getting the developer who wrote this to do it in a more sensible way but I believe there is a Drools issue here as well. 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. I've updated the demo project to reflect this. We're certainly getting the develop who wrote this to do it in a more sensible way but I believe there is a Drools issue here as well. > 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

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