February 2020 - jboss-jira - Jboss List Archives

[JBoss JIRA] (DROOLS-4201) DMN - Client-Side Marshalling

by Matteo Mortari (Jira)

[ https://issues.redhat.com/browse/DROOLS-4201?page=com.atlassian.jira.plug... ] Matteo Mortari commented on DROOLS-4201: ---------------------------------------- [~gabriolo] I am pruning backlog, I believe this was already performed by you / Kogito tooling scrumteam. Feel free to close as done as required. > DMN - Client-Side Marshalling > ----------------------------- > > Key: DROOLS-4201 > URL: https://issues.redhat.com/browse/DROOLS-4201 > Project: Drools > Issue Type: Task > Reporter: Alexandre Bakos > Assignee: Gabriele Cardosi > Priority: Major > -- This message was sent by Atlassian Jira (v7.13.8#713008)

4 years, 8 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-4201) DMN - Client-Side Marshalling

by Matteo Mortari (Jira)

[ https://issues.redhat.com/browse/DROOLS-4201?page=com.atlassian.jira.plug... ] Matteo Mortari commented on DROOLS-4201: ---------------------------------------- I believe this was raised for (kogito) and tooling purposes, and actually I believe it was already done by the Kogito tooling scrumteam and Gabriele, reassigning. > DMN - Client-Side Marshalling > ----------------------------- > > Key: DROOLS-4201 > URL: https://issues.redhat.com/browse/DROOLS-4201 > Project: Drools > Issue Type: Task > Reporter: Alexandre Bakos > Assignee: Matteo Mortari > Priority: Major > -- This message was sent by Atlassian Jira (v7.13.8#713008)

4 years, 8 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-4201) DMN - Client-Side Marshalling

by Matteo Mortari (Jira)

[ https://issues.redhat.com/browse/DROOLS-4201?page=com.atlassian.jira.plug... ] Matteo Mortari reassigned DROOLS-4201: -------------------------------------- Assignee: Gabriele Cardosi (was: Matteo Mortari) > DMN - Client-Side Marshalling > ----------------------------- > > Key: DROOLS-4201 > URL: https://issues.redhat.com/browse/DROOLS-4201 > Project: Drools > Issue Type: Task > Reporter: Alexandre Bakos > Assignee: Gabriele Cardosi > Priority: Major > -- This message was sent by Atlassian Jira (v7.13.8#713008)

4 years, 8 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-4967) decision table rules are not loaded into kiebase

by Mario Fusco (Jira)

[ https://issues.redhat.com/browse/DROOLS-4967?page=com.atlassian.jira.plug... ] Mario Fusco resolved DROOLS-4967. --------------------------------- Resolution: Explained > decision table rules are not loaded into kiebase > ------------------------------------------------ > > Key: DROOLS-4967 > URL: https://issues.redhat.com/browse/DROOLS-4967 > Project: Drools > Issue Type: Bug > Components: decision tables > Affects Versions: 7.21.0.Final, 7.22.0.Final, 7.23.0.Final, 7.24.0.Final, 7.25.0.Final, 7.26.0.Final, 7.27.0.Final, 7.28.0.Final, 7.29.0.Final, 7.30.0.Final, 7.31.0.Final > Reporter: Volodymyr Shymkiv > Assignee: Mario Fusco > Priority: Blocker > Attachments: CanDrink2.xls, CanNotDrink2.xls > > > When compiling xls decision table, wrong ruleset name is parsed from the xls file. This can lead to multiple issues, like rules being filtered out by kmodule.xml configuration. > According to documentation, decision table begins with a cell at second or third column, having value RuleSet. The cell on the right of this one contains the name of the rule set, which we want to use as a package name. > The problem lies in naive approach to parsing the package name from the xls file. As you can see in project drools-compiler, class org.drools.compiler.kie.builder.impl.KieBuilderImpl method packageNameFromDtable, it execute as follows: > # find "RuleSet" string in the binary data > # find and return the nearest string which can act as a valid java package name > The problem is, the string returned from packageNameFromDtable is NOT the value of the cell next to the RuleSet. It is actually a value of a random cell. > To understand the problem, we need to understand the binary content of the actual xls file. Every cell is presented as a few bytes, containing cell's value, position, and other information. The "problematic" thing here is, the _order_ of the cells in the binary data is NOT constant. BUT the code really just reads the cell _binary_ next to the "RuleSet" cell. > Problem is present since version 7.21 as it is caused by a fix for DROOLS-3888 - commit 9a179b6e6b955889200b0258ccd18cd1a5f14b46 > In our case, this results in rules not being loaded, as they are filtered out by kmodule.xml configuration. We have a lot of decision tables we want to migrate from an older drools version, and most of them are now ignored due to this bug. -- This message was sent by Atlassian Jira (v7.13.8#713008)

4 years, 8 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-4645) High memory consumption with JIT

by Mario Fusco (Jira)

[ https://issues.redhat.com/browse/DROOLS-4645?page=com.atlassian.jira.plug... ] Mario Fusco resolved DROOLS-4645. --------------------------------- Resolution: Cannot Reproduce > High memory consumption with JIT > -------------------------------- > > Key: DROOLS-4645 > URL: https://issues.redhat.com/browse/DROOLS-4645 > Project: Drools > Issue Type: Bug > Components: executable model > Affects Versions: 7.29.0.Final > Reporter: Radovan Synek > Assignee: Mario Fusco > Priority: Critical > Attachments: Screenshot from 2019-10-15 10-30-27.png, Screenshot from 2019-10-15 10-31-53.png > > > Employee Rostering example for OptaPlanner shows excessive memory consumption, which is connected with Drools score calculation. > Please see the reproducer - running it without drools JIT finishes on time with 3GB of memory while with drools JIT being active it fails due to "GC overhead limit exceeded" despite the fact it god twice as much memory. > Logging (add -Dlogback.level.org.optaplanner=trace to the execute_jit.sh script) showed there is a huge pillar move changing ~hundreds of entities which takes seconds to calculate score. During this move's evaluation, the memory consumption increases to a point when GC takes over and later fails. > Memory sampling and heap dump investigation showed there are ~10^7 objects of org.drools.core.reteoo.FromNodeLeftTuple class, taking more memory than any other data type in the VM. > See the attached screenshots. -- This message was sent by Atlassian Jira (v7.13.8#713008)

4 years, 8 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-4967) decision table rules are not loaded into kiebase

by Mario Fusco (Jira)

[ https://issues.redhat.com/browse/DROOLS-4967?page=com.atlassian.jira.plug... ] Mario Fusco commented on DROOLS-4967: ------------------------------------- [~acc_team] The xls you attached just has the wrong package and import. (Sorry I did the same mistake with mine). If you fix both you'll see that MultiKieBaseTest is passing as expected. In other words I still cannot reproduce the problem. Can you? > decision table rules are not loaded into kiebase > ------------------------------------------------ > > Key: DROOLS-4967 > URL: https://issues.redhat.com/browse/DROOLS-4967 > Project: Drools > Issue Type: Bug > Components: decision tables > Affects Versions: 7.21.0.Final, 7.22.0.Final, 7.23.0.Final, 7.24.0.Final, 7.25.0.Final, 7.26.0.Final, 7.27.0.Final, 7.28.0.Final, 7.29.0.Final, 7.30.0.Final, 7.31.0.Final > Reporter: Volodymyr Shymkiv > Assignee: Mario Fusco > Priority: Blocker > Attachments: CanDrink2.xls, CanNotDrink2.xls > > > When compiling xls decision table, wrong ruleset name is parsed from the xls file. This can lead to multiple issues, like rules being filtered out by kmodule.xml configuration. > According to documentation, decision table begins with a cell at second or third column, having value RuleSet. The cell on the right of this one contains the name of the rule set, which we want to use as a package name. > The problem lies in naive approach to parsing the package name from the xls file. As you can see in project drools-compiler, class org.drools.compiler.kie.builder.impl.KieBuilderImpl method packageNameFromDtable, it execute as follows: > # find "RuleSet" string in the binary data > # find and return the nearest string which can act as a valid java package name > The problem is, the string returned from packageNameFromDtable is NOT the value of the cell next to the RuleSet. It is actually a value of a random cell. > To understand the problem, we need to understand the binary content of the actual xls file. Every cell is presented as a few bytes, containing cell's value, position, and other information. The "problematic" thing here is, the _order_ of the cells in the binary data is NOT constant. BUT the code really just reads the cell _binary_ next to the "RuleSet" cell. > Problem is present since version 7.21 as it is caused by a fix for DROOLS-3888 - commit 9a179b6e6b955889200b0258ccd18cd1a5f14b46 > In our case, this results in rules not being loaded, as they are filtered out by kmodule.xml configuration. We have a lot of decision tables we want to migrate from an older drools version, and most of them are now ignored due to this bug. -- This message was sent by Atlassian Jira (v7.13.8#713008)

4 years, 8 months

1
0
0 / 0

[JBoss JIRA] (SWSQE-1063) Fix incorrect parameter types

by Filip Brychta (Jira)

[ https://issues.redhat.com/browse/SWSQE-1063?page=com.atlassian.jira.plugi... ] Filip Brychta resolved SWSQE-1063. ---------------------------------- Resolution: Done > Fix incorrect parameter types > ----------------------------- > > Key: SWSQE-1063 > URL: https://issues.redhat.com/browse/SWSQE-1063 > Project: Kiali QE > Issue Type: Sub-task > Reporter: Filip Brychta > Assignee: Filip Brychta > Priority: Major > > Some jobs are passing boolean params as strings, we need to fix that. > It's causing warnings like: The parameter 'DELETE_MAISTRA_OPERATOR' did not have the type expected by clean-environment. Converting to Boolean Parameter. -- This message was sent by Atlassian Jira (v7.13.8#713008)

4 years, 8 months

1
0
0 / 0

[JBoss JIRA] (WFLY-13011) The quickstart template appears out of date

by Eduardo Martins (Jira)

[ https://issues.redhat.com/browse/WFLY-13011?page=com.atlassian.jira.plugi... ] Eduardo Martins commented on WFLY-13011: ---------------------------------------- [~rchakrab] I will soon work out this one. > The quickstart template appears out of date > ------------------------------------------- > > Key: WFLY-13011 > URL: https://issues.redhat.com/browse/WFLY-13011 > Project: WildFly > Issue Type: Bug > Components: Quickstarts > Affects Versions: 19.0.0.Beta1 > Reporter: Darran Lofthouse > Assignee: Eduardo Martins > Priority: Major > > The quickstart template appears to be out of date based on the present requirements. > One example it does not contain the technologies attribute which leads to a NullPointerException when building the docs with a new quickstart using the template. > Additionally later quickstarts appear to use an abstract differently to how the template describes them to define some more values so it would be nice to see some description of how this should be used. -- This message was sent by Atlassian Jira (v7.13.8#713008)

4 years, 8 months

1
0
0 / 0

[JBoss JIRA] (WFLY-13011) The quickstart template appears out of date

by Darran Lofthouse (Jira)

[ https://issues.redhat.com/browse/WFLY-13011?page=com.atlassian.jira.plugi... ] Darran Lofthouse commented on WFLY-13011: ----------------------------------------- The issue was if you create a new quickstart by copying over the template project the readme triggers a npe when generating the docs - TBH it seems more a set of instructions than a template. > The quickstart template appears out of date > ------------------------------------------- > > Key: WFLY-13011 > URL: https://issues.redhat.com/browse/WFLY-13011 > Project: WildFly > Issue Type: Bug > Components: Quickstarts > Affects Versions: 19.0.0.Beta1 > Reporter: Darran Lofthouse > Assignee: Eduardo Martins > Priority: Major > > The quickstart template appears to be out of date based on the present requirements. > One example it does not contain the technologies attribute which leads to a NullPointerException when building the docs with a new quickstart using the template. > Additionally later quickstarts appear to use an abstract differently to how the template describes them to define some more values so it would be nice to see some description of how this should be used. -- This message was sent by Atlassian Jira (v7.13.8#713008)

4 years, 8 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-5009) DMN Designer convert java class with invalid DMN identiefier

by Michael Anstis (Jira)

[ https://issues.redhat.com/browse/DROOLS-5009?page=com.atlassian.jira.plug... ] Michael Anstis commented on DROOLS-5009: ---------------------------------------- [~dadossan] It seems reasonable enough to me. Should we seek UX opinion too? > DMN Designer convert java class with invalid DMN identiefier > ------------------------------------------------------------ > > Key: DROOLS-5009 > URL: https://issues.redhat.com/browse/DROOLS-5009 > Project: Drools > Issue Type: Bug > Components: DMN Editor > Affects Versions: 7.33.0.Final > Reporter: Jozef Marko > Assignee: Daniel José dos Santos > Priority: Minor > Labels: drools-tools > Attachments: Screenshot from 2020-02-05 16-21-10.png > > > There is an issue if user convert java class to DMN data type while the java class contains field name, that is invalid identifier for DMN. > for example assume this java class and try to convert it into DMN data type, you will get an error as attached. > {code:java} > public class Address { > private int number; > } > {code} -- This message was sent by Atlassian Jira (v7.13.8#713008)

4 years, 8 months

1
0
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-jira February 2020